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Legitimate Concerns 



I recently spent some time in southern 
A rizona, an area with dark skies, low 
humidity, and still air. Throw in 
some high desert and mountains to 
give a few thousand feet more eleva- 
tion and it's understandable that the 
area is a hotbed for astronomy, both 
professional and amateur. 
As with many of you, science fiction 
was the staple of my literary diet from third 
grade on, until it seemed that I'd read 
everything from Asimov to Zelazny (Poul 
Anderson may come before Asimov in the 
alphabet, but not in my heart). Those sto- 
ries of starship troopers. Bene Gesserit, 
lensmen, K'Zinti, and their like, became 
part of what I saw when I looked at the 
night sky. 

Since I grew up in pretty much urban 
areas, I was mostly confined to stars of the 
first few magnitudes, the moon, and the 
more obvious planets. N evertheless, it was 
always my conviction that if I could just see 
well enough, I would see a universe filled 
with ships flying on solar sails, generation 
ships carved from asteroids, fleets of inter- 
stellar transports picking their way through 
foggy nebulas, and stars winking out as the 
last section of their Dyson spheres were 
nailed into place 

Recent photos from the H ubble 
Space Telescope reminded me of those 
dreams. Recent images from the G reat 
Nebula of Orion show "cosmic eggs," 
their three-dimensional structure perfectly 
lit by conveniently placed protostars. The 
most spectacular space effects from Pixar 
and Industrial Light and M agic have 
nothing on these photos for sheer beauty. 
So when I was in Arizona, I made sure 
that I was introduced to someone with an 
"amateur" telescope, an 11-inch Schmidt- 
Cassegrain with worm-gear corrected 
equatorial mount and a computerized 
tracker containing virtually the entire 
M essier catalog of deep- space objects. Of 
course, I knew I was not going to see any- 



thing similar to the H ST photos, but I 
did hope that on a clear night with no 
moon, I would see my first nebula. 

The photos in Sky Si Telescope maga- 
zine don't do modern amateur telescopes 
justice E d, the scope's owner, has a special 
indoor/outdoor room to house his equip- 
ment. H e moves the 11- inch scope with a 
hand- truck out onto his patio. Tucson is a 
town remarkably conscious of light pollu- 
tion due to its proximity to the Kitt's Peak 
observatory, and excellent viewing can be 
had in the suburbs. After setting up the 
telescope in rough approximation with 
Polaris, Ed centered Deneb in the tracking 
scope and punched a button or two on the 
mount's control panel. 

A few minutes later, the computer 
had seen enough to do three-dimensional 
transformations worthy of C hris H ecker to 
calculate its exact orientation relative to the 
Earth's axis. At that point, the computer 
and precision motors kept objects only a 
few arcseconds wide locked in the center of 
the view, despite the Earth's rotation. A 
charge-coupled device (CCD) can give the 
even more precise control necessary for 
long- exposure photography 

The computer handles one more 
task. Ed types in a M essier number and 
rotates the tube until the L E D display 
indicates precise alignment. W ithout 
looking through the spotting scope, he 
invites me to take a look. 'T hat's the C rab 
Nebula," he says. Chinese astronomers 
have precise records of the appearance of 
the nova that created the nebula, an 
explosion so epochal that it could be seen 
in daylight. I look out and back into time 
The nebula appears as a faint puff of 
smoke, gray against black. Not even a 
thousand years after the explosion, the 
remains of the star are spread over light 
years. Roughly 6 trillion miles in a light 
year, cubed is 256 times 10 to the 12th to 
the 3rd, so the volume of a single light 
year is roughly, uh, really, really big. But 
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there it is, rocl< steady in the eyepiece, a 
structure so vast I can't even tame it with 
exponents. 

E d has a flare for the dramatic and 
turns to the other extreme, the G reat 
N ebula of rion, and shows me another 
faint puff of smol<e H e mal<es sure I note 
some of the stars embedded in the nebula 
and tells me I 'm seeing the birth flares of 
stars newborn just a million years ago. 
The H ST photos were of this area and a 
thousand times more detailed and color- 
ful, but there is something far more pow- 
erful about the ancient light falling 
directly on my retina. 

Finally, Ed shows me the Androme- 
da Galaxy. It's 250,000,000 light years 
away, but it's so large that it doesn't even 
fit in the field of view. The extended 
shape of the galaxy is apparent, but no 
structure— like the nebulas, it appears as a 
blob of grey that otherwise might be 
taken for a lens smudge. But to me, it 
instantly brings back those childhood 
dreams of worlds like grains of sand. A n 



entire galaxy glowing as a homogenous 
whole from its stars. 

The point I'm trying to get at is that 
many of the most powerful experiences 
available to us are not inherently 
grandiose. If there are two experiences 
and one is somehow felt as "more legiti- 
mate," it won't matter if the other is more 
detailed, longer lasting, or more comfort- 
able. H uman eyes will never see the col- 
ors and details of an astronomical photo- 
graph. But looking through a telescope is 
better. Any night on The Discovery 
Channel, I can see better images of 
sharks and whales than I've ever seen 
underwater. But I'd never trade a single 
dive for all the film in the world. 

As designers of digital entertain- 
ment, we have to always remind ourselves 
that we will never create experiences as 
physically legitimate as the simplest activ- 
ity. There is not a fighting game that 
compares to capture the flag, not a sports 
game that compares to dodge ball, not a 
strategy game that compares to cutting 



over on the frontage road to avoid traffic. 
So we must create our legitimacy from 
game play. W e must never smirk at the 
universe we create (unless our universe 
does nothing but smirk), we must never 
wink at the player and say, "W e both 
know this couldn't happen, but you'll for- 
give me because we both know this is just 
a computer game." 

Too many games rely on just such 
tactics, relying on either A I that cheats or 
stories with very limited branching. Game 
design, A I, and story-telling will be major 
themes of Game Developer in 1996, and 
we're excited to kick off our third year of 
publication with a major article on genetic 
algorithms, beginning on page 26. 

W hen we are done, E d trundles his 
telescope back into its private room. As I 
walk away, I wonder what chip powered 
its computer. A Z-80? A n 8086? W ho 
says you need 32 bits to have fun? ■ 

Larry 'B rien 
Editor 
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Go On! 
(Line, 



That Is) 



Alex Dunne 

Vou need fo sfoy on 
fop of things fomahe 
if OS gome develop- 
er. Here, Hlex Dunne 
gives ijou some 
reseorcli ossis- 
fonce — fie's fiunfed 
doiun some IIIILs i]ou 
simply connof offord 
fo miss. 



If you've been scanning the book- 
shelves and magazine racl<s, 
you've noticed that the number 
of words devoted to game pro- 
gramming isn't quite on par with 
the demand generated by devel- 
opers. Information on developing 
games is sparse. There is more 
information available to developers of 
web sites, general business applica- 
tions, and the like. If you're like many 
others in this industry, you've either 
begun to scan web sites and ftp 
archives and online services such as 
CompuServe, America Online, and 
M icrosoft Network for programming 
information or you're about to. 

Unfortunately, the wired world 
moves in mysterious ways, and trying 
to locate current, pertinent informa- 
tion on the W orld W ide W eb and 
online services can be a time-consum- 
ing experience. It's nice to have direc- 
tions before setting out on this road. 
I 've pieced together my favorite sites 
from long hours of browsing, which 
will hopefully save your eyes and your 
telephone bill from ruin. We'll be 
transferring this information to the 
G ame D ev eloper web site shortly (prob- 
ably by the time you read this), so 
don't worry about copying down the 
long URLs. 

If you come across some new web 
or ftp sites that you'd like to let other 
developers in on, let us know. Our goal 
is to turn our own web site into a launch- 
ing point for other information on the 
Internet, and we'll need your help to 
keep our links hot and fresh. Send your 
recommendations to gdmag@mfi.com 
with the subject line"H ot URL." 




The World 
Wide Web 

i^fl As evidenced by 
N etscape's ridiculous 
stock price, the web is 
growing so fast we can't keep up with it. 
For this reason, the information you find 
on the net is both fresh as this morning's 
Starbucks and as old as that tin of Folger's 
Crystals in the back of your pantry. As 
many web pages went up yesterday as the 
number of pages that haven't been updat- 
ed in the past year. So the web can be an 
extremely efficient means of getting the 
information you want, or a time-consum- 
ing chase across the world that terminates 
at an antiquated site. H ere are some good 
sites to visit for game development topics. 

• 3D G raphics E ngi nes page (http:// 
www.(s.tu-berlin.d^H<i/engineshtml) A 
fairly fleshed-out list of texture map- 
ping engines, Gouraud shading 
engines, landscape rendering engines, 
flat-shading engines, and more. A bit 
like a buyers guide, with links to ven- 
dor home pages. 

• Algorithm's G raphics H otiist (http:// 
www .algorithm.com/graphic5/graph 
hot. html) This contains links to all 
sorts of graphics- related pages and, 
like the V irtual L ibrary, is a good 
launching point. 

• Computer Game Da/ elopers Con ferencE 
(CGDC) (http://www.mfi.com/sd 
confs/cgdc) Information about the 
West Coast version of the game 
developer's conference. Conference 
schedule, location, and more 

• Computer Graphics M iscellaneous FAQ 
(http://www. algorithm, com/ 
graphics/graphhot.html) A list of fre- 
quently asked questions ("H ow do 
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I.."; "Where can I find...") about 
graphics as well as pointers to other 
sites. U pdated fairly regularly. 
■ Denthor of Asphyxia and the Asphyxia 
T rainers (http://goth.vironix.co.za/ 
-denthor/) Don't ask me about the 
name, but this site offers about 20 
downloadable tutorials, such as "wid- 
gets and gismos," "crossfading," "full- 
screen scrolling," "starfields," "pixel 
morphs," "scaling bitmaps," and more 

• Egerter Software (http://peace.w it. 
com/ -kosmi c/gooroo/softw are. html ) A 
small Canadian software company 
posting three graphics programming 
tutorials and two rendering engines. 

• Ethan Brodsky's page. (http://www. 
xraylith.wisc.edu/~ebrodsky/) A source 
of information for programming 
Sound Blaster audio cards. 

• Game Resource Page (http://www.es. 
umu.s^~dirister/GR/) A directory of 
game programming sites divided into 
algorithms, graphics, FAQs, book 
publishers, and more. 

• Game D a/elopers Contact L ist (http:// 
www.gamesdomain.co.uk/gamedev/ 
reslist.html) Conceptually a great idea, 
but it could be updated more frequently 
(it's two months old as I write this). A 
clearing house of people interested in 
various areas of game development 
(writers, programmers, musicians) who 
want to get matched up with others in 
the field. A bit like the personals sec- 
tion of your local newspaper. 

• Knut's Homepage (http://www. 
oslonett.no/home/oruud/homepage.htm) 
This page contains information about 
game programming and graphics. It 
also contains links to shareware and 
freeware graphics and sound libraries 
available on the Internet. 

• G ame D eveloper magazine (http:// 
www.mfi.com/gdmag) I'll be immodest 
and recommend that you check out 
our site. Up to this point, we've been 
tentative about making a big splash on 
the web because our resources are fairly 
stretched just producing a print version 
of the magazine But we're revamping 
our web site and will be relaunching it 
with a new interface and new content. 

• Game Development Tools Listing 
(http://www.cs.umu.Se/~christer/G R/ 



game_company_pagehtml) This page 
lists company web sites broken down 
by product category, such as "E nter- 
tainment Producers," "Hardware 
M anufacturers," and "M ultimedia 
Software Manufacturers." Listed 
alphabetically. Very handy. 

• N exus Game Programming L inks Page 
(http://w w w . ga mesd om a i n. co.uk/ 
gameda//gprog.html) Based out of the 
U.K., a well-maintained site for "all 
things game- related on the I nternet." 

• Searching: D ejaN ews (http://www . 
d^anefl/scom) This is an incredible site 
that searches for Usenet newsgroups 
based on keywords you enter. Looking 
for every mention of the term "texture 
mapping" in rec.games.programmer? 
A Iternatively, check to see if anyone's 
been talking about you online 

• Seardiing: Savvy Search (http://www. 
cs.colostate.edu/~dreiling/smartform. 
html) A search engine that sends your 
query in parallel to other search 
engines including Yahoo, Lycos, Web 
Crawler, and NIKOS (about 15 in all) 
and displays the results in a single list. 

• Seardiing: Yahoo's Seardi Engine M aster 
List (http://www. yahoo. com/Comput- 
ers_and_l nternet/l nternet/World_ 
Wide_Web/Seardiing_the_Web/) This 
lists most of the search engines avail- 
able on the web. T ake your pick. 

• Watcom Corporation (http://www.wat- 
com.on.ca/tfchtml) Information about C 
and C-i-f-. Watcom has downloadable 
tutorials for those learning the lan- 
guage, links to other CIC++ resources, 
and a library of source code 

• WW W Virtual L ibrary of Computer 
Graphics (http://www .dataspace. 
com/WWW/vlib/comp-graphic5.html) If 
you want a comprehensive list of 
papers, organizations, and commercial 
sites dedicated to graphics, this is a 
good place to start. 



and cut and paste (careful with the copy- 
rights though). 

• Borland's FTP Site (ftp://ftp.borland. 
CDm/pub/tediinfo/index.html) Whether 
you're looking for C, C-l-f-, or Pascal 
source code or support, Borland's put 
together a comprehensive site that's 
logically organized. 

• C reati ve L abs's F T P site (ftp://ftp. 
aeaf.com) Sound files, utilities, and 
the like. 

• DEC'S FTP Site (http://ftp. digital, 
rom/cgi-bin/grep- index) Digital's has a 
large library of source code for a num- 
ber of games. M ost of the code isn't 
that fresh, but nevertheless it's inter- 
esting to browse. 

• Fastgraph FTP Site (ftp://ftp.aoce55nv. 
com/fg/) This is where you can find 
the shareware version of the Fast- 
graph graphics library (for PC ). T here 
are also articles and chapters from 
Action Arcade Adventure Set (Coriolis 
Group, 1994). 

• Game Developer magazine (ftp://ftp. 
mfi.com/pub/gamedev/src/) You can 
find the source code from our back 
issues at this location. 

• Game Programming Archives at Oulu 
University, Finland. (ftp://x2ftp. 
oulu.fi/pub/msdo^programming/) This 
is a huge site with many different files 
for downloading, ranging in topic 
from graphics to Al, game program- 
ming theory, sound, and much more. 
M any web directories have links to 
this source, as it's very comprehensive. 
W ord has it that it's not being updat- 
ed anymore, however. 

• M icrosoft FTP site (ftp://ftp. microsoft, 
oam/dirmap.htm) This page helps you 
navigate through the myriad files 
found at M icrosoft. 

• ModeX Introduction (ftp:// x2ftp.oulu. 
fi/pub/msdos/programming/docs/xin- 
trol8.zip) Self-explanatory, eh? 




File Transfer y^t^ Online Service: 

Protocol (FTP) ^n^^ CompuServe! 

H Sites ^■i^mj I admit I'm heavily 



These sites allow you to ^H^P biased toward C om- 

download files (usually puServe. I've tried 

zipped— make sure you've got PKunzip A merica Online and the M icrosoft 

handy) for offline viewing, inspection, Network, and found both of them 
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extremely lacking in technical informa- 
tion. CompuServe, on the other hand, 
has a fairly rich offering of technical 
forums, hosted by magazines and soft- 
ware and hardware vendors. W hat 
mal<es these forums so valuable, howev- 
er, isn't these corporate sponsors, but 
the CompuServe members who hang 
out in these areas. M ost have technical 
backgrounds, contribute frequently to 
forum libraries, participate in discus- 
sions, and answer your questions. T hese 
forums are moderated either by 
employees of the sponsor or other citi- 
zens, such as yourself, which helps filter 
out spams, flames, and other noise. If 
you only belong to one online service, 
this is the one. H ere are some forums to 
visit: 

• Autodesk M ultimedia Forum (GO 
ADESK) has project/mesh files for 
3D Studio and support for both 3D 
Studio and Animator Pro. If you're 
using either of these Autodesk tools, 
this is your spot. 

• CASE Forum (GO CASE FO) is a 
forum where issues such as software 
engineering, software quality, and 
development teamwork are discussed. 

• Dr. Dobb's Journal Forum (GO DDJ- 
FORU M ) is sponsored by the maga- 
zine of the same name. It contains 
libraries on CIC++, artificial intelli- 
gence, and of course code from the 
magazine itself. 

• Game Developer's Forum (GO 
GAM E D E V) contains good discus- 
sions and searchable library sections on 
Windows programming, DOS pro- 
gramming, online and modem games, 
design theory, hardware issues, and 
more. Game kits, sample code, and 
FAQ sheets galore. Advice on tools 
and techniques. 

• Game Players' Forum (GO GAM ERS) 
is a forum for game players. It contains 
comments about games, cheat files and 
codes, and so on. A good barometer of 
what players like and hate. 

• M io-osoftM ultimedia(GO WINM M ) is 
the official M icrosoft forum for multi- 
media and game development with 
W indows. 

• Software D evelopment F orum (G 
SD FORU M ) contains source code 



CompuServe has o 
rich offeriRQ o ' 
fechnicol forums, 
hosted hij moQO- 
zines and hord- 
uiare and sofF- 
uiare vendors. 



from Game D eveloper magazine and 
sections devoted to C-i-f-, Visual Basic, 
object-oriented programming, and 
more. 

Visual Basic Forums (GO VBPJ, GO 
M SBASIC) are two forums useful for 
VB programmers. 



read the group's FAQ before you post 
any questions. That saves bandwidth 
and prevents people from having to 
answer a question that might have been 
answered ten— or 100— times already. 

• 3D programming information (ftp:// 
x2ftp.oulu.fi/pub/msdos/programming/ 
faq/3d-prog.l8) 

• BSP treeFAO (http://www.qualia. 
mm/bspfaq/) 

• Getting Started in Game Development 
F AO (ftp://ftp.acce55nv.com/fg/misc/ 
gamefaq.txt) 

• mmp.graphics FAO (ftp://x2ftp.oulu.fi/ 
pub/msdos/programming/faq/graphics. 
faq) 

• comp.graphics.algorithms F AO (http:// 
www.d5.ohio-stateedu/hypertext/faq/ 
usenet/graphic^algorithmsfaq/faq.html) 

• comp.graphic5.animation FAQ (ftp:// 
x2ftp.oulu.fi/pub/m5do5/programming/ 
faq/animatio.l2) 

• comp.lang.c F AO (ftp://rtfm. mit.edu/ 
pub/usenet/newsanswer^C-faq/faq) 

• recgames.programmer FAQ (http:// 
w ww.eeud. ac.uk/ -phart/gam^F AO/ 
rgp_FAO.html) 

• rec.games.design FAQ (ftp://x2ftp. 
oulu.fi/pub/msdo^programming/faq/desi 
gn.201) 

• ModeX FAO (ftp://x2ftp.oulu.fi/pub/ 
msdo^programming/faq/modex.faq) 

• PC soundcards F AO (http://www. 
d5.ohio- state, edu/hypertext/faq/usend/ 
PCsoundcard^soundcard-faq/faq.html) 

• Tile- based games FAO (http://www. 
io. mm/ ~paulhart/FAQ/ti lefaq.html) 




W 



Frequently 
Asked 
Questions 
(FAQs) 

D you want to learn about a particular 
topic, such as 3D programming, but 
you don't know the right questions to 
ask? T ry a FAQ sheet. M any FAQ 
sheets describe Usenet newsgroups for 
which they were created, but they're 
more than just newsgroup descriptions. 
Questions that keep getting asked in 
these newsgroups get added to the 
newsgroup FAQs, and if you are new to 
a newsgroup, you are often instructed to 



Open the Floodgates... 

You probably know of a number of sites 
that I haven't mentioned here. H ey, for 
that matter, so do I ! Unfortunately, 
space constraints don't allow me to 
print every worthy site. For that reason, 
we'll be extending this list and posting 
it on our own web site. Start sending us 
your URLs! ■ 



Alex D unne is a contributing editor 
to Game Developer magazine Contact 
him via e-mail at 76702. 1142@com- 
puservecom. 
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Shoe king 
-the Monkey 



Diane Anderson 

Find ouf uihof [he 
Infernei may mean 
for Qome progrom- 
mino — if can be 
"pouiered by Shocli- 
inove" noinodoys. 
Hnd see uibo's 
upgrading inhof, 
uihen, and boui much 
'II cosf. 



When you visit the Toy Story site, 
you can see the delightful charac- 
ters created by Pixar. W oody and 
Buzz Lightyear have a game- 
simple and silly, but a game nonethe- 
less. I t's a game developed using the lat- 
est Director technology— a memory 
game, you know, like the H usker D u 
gameyou played as a child in which you 
turn over a card and try to find a match? 
W ell, Shockwave users get to turn over 
cards of Toy Story characters and search 
for matches. Okay, so it isn't an intel- 
lectually gruelling game of chess. But 
this new technology should mean some 




big things for interactive game pro- 
gramming. It is definitely worth the 
time it takes to examine what M acro- 
media is doing with Director and 
Shockwave. Check out M acromedia's 
web site at http://www. macromedia, 
com. If you have the right version 
(which happens to be 2.0 at the exact 
moment of this writing) of Netscape 
and are running W indows 95, you won't 
be bored by a static screen. You can see 
what's happening at M eirose Place, 
c/net, DC Comics, Intel, MTV, CNN, 
and the American Cancer Society. Your 
monitor will be animated, which may 
not be new, but coming over the I nter- 
net, it is pretty exciting. Check it out 
and then get started making interactive 
games for the net yourself. 



GeiVouf NflCfosHere 

The M acromedia folks are up to other 
things besides Shockwaving their pro- 
grams. W hile Afterburner and Shock- 
wave might seem cool enough to the 
average bear, M acromedia has introduced 
Extreme 3D for cross- platform modeling, 
rendering, and animation. I fuses Director 
to provide advanced data filtering, visual 
feedback, interactive keyframe manipula- 
tions, and cut and paste in a single win- 
dow. It costs $699. (They also agreed to 
acquire SC , makers of digital audio pro- 
duction software.) 

■ For more information contact: 
iv| acromedia 
600 Townsend St. 
San Francisco, Calif. 94103 
Tel: (415) 252-2000 
Fax: (415) 626-1502 



Is 3D Space True? 



Caligari Corp. announced its 3D product, 
T rueSpace2. T rueSpace2 uses I ntel's 3D R 
acceleration to let the user create and ren- 
der with drag-and-drop capabilities. Users 
can perfom 3D Boolean operations and 
model scenes. TrueSpace2 has PostScript 
capabilities in which the user loads 2D 
drawings in an .EPS format into 3D 
spaces. The program for W indows costs 
$499, but you can order a free C D - R M 
trial version if you agree to fork over 
$14.95 to cover shipping and handling. 
■ For more information contact: 

Caligari Corp. 

1955 Landings Dr. 

Mountain View, Calif. 94043 

Tel: (415) 390-9600 

Fax: (415) 390-9755 
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Softkey yanked the rug out from under 
Broderbund's acquisition of The 
Learning Company witli a hostile 
takeover bid. They went on to complete 
their edutainment triple play by buying 
Compton's New Media and jviecc 
(makers of Oregon Trail). Will these com- 
panies experience the fate of Softkey 
company WordStar— now just another 
low-cost retail relicensor? According to 
J ames Sigismonti, Compton's Senior 
Producer, Softkey says it wants Comp- 
ton's to keep up its quality development. 
But Softkey shareware developers allege 
Softkey has refused to pay them. Can 
Softkey, who is closing in on the #2 spot 
in software sales, change its low-end 
image?Are developers atthe hands of 
miserly monopolies? 

And from the #1 software company, 
Microsoft announced they bought 
Bruce Artwiclc's company, developer 
of the highly successful Microsoft 
Fligfit Simulator. M icroSoft 
cofounder, Paul Allen purchased 5% of 
Broderbund stock for his own use. 

Larry Kasanoff's Threshold 
Entertainment creators of the Mor- 
tal Kombat movie, secured film rights 
to both The Seventh Guest and 11th 
Hour, brainchildren of Trilobyte. 

Sources at M icroSoft indicate that 
Direct Draw in on track with the recent 
ship on MSDN. Direct Play still has a 
long way to go before being really useful. 
Direct Sound is in much better shape. 
Direct 3D should be in the hands of 
developers early next year with the cur- 
rent build fast, but not fast enough yet. 

Technologist Steve Crane, recently 
with Knowledge Adventure, has 
joined Activision. Senior Producer 
Leonard MIodinow, of Knowledge 
Adventure, is now bringing his sense of 
humor to Disney Interactive. J eff 
Dee, formerly Art Director with Simtex, 
has joined Illusion Machines incor- 
porated. J osh Davidson, producer 
for Microsoft, has moved to Dream- 
works interactive in L A. as part of 
the M icrosoft-Dreamworks joint venture. 
J ason Rubenstein, formerly of the 
imagiNation Network, has joined 
Dreamworks interactive's market- 
ing. Geoffrey Selzer has joined Dis- 
ney interactive. Executive Producer 
Lisa Linnenkohl, mostly recently with 
Star Press Multimedia, has joined 
Palladium interactive. 

Wanna gossip? E-mail The Gossip 
lady at: 71501.3553@compuserve.com. 



Blast IN 



C reative T echnology L td. (Creative 
Labs) announced a new version of its 
3D game board, 3D Blaster for 486 VL- 
BUS PCs. Now there's Sound Blaster, 
Phone Blaster, M odem Blaster, and 3D 
Blaster. Creative seems to be working 
with M icrosoft to bring 3D to every 
Pentium. 3D Blaster will be available 
this spring and should retail for about 
$349; it will be bundled with software 
titles, like M agic Carpet, that were cre- 
ated using C reative L abs's product. 
■ For more information contact: 

C reative Labs 

1901 McCarthy Blvd. 

Milpitas, Calif. 95035 

Tel: (408) 428-6600 

Fax: (408) 428-2394 



Use Tool 



The company formerly known as H SC 
Software is now renamed to be known as 
M etaT ools Inc. M etaT ools has an- 
nounced that Kai Power Tools and KPT 
Convolver can now plug into Autodesk's 
Animator Studio. These extensions for 
Windows let animators blend, texturize, 
and saturate their animations. T hese 
imaging tools let you create gradients, 
fractals, transparency effects, explosion 
effects, particle effects, moving bubbles, 
and spheres. You can adjust hue, sharp- 
ness, contrast, relief, and edges of an 
object or area using the KPT Convolver. 
■ For more information contact: 

MetaTools inc. 

6303 Carpinteria Ave. 

Carpinteria, Calif. 93013 

Tel: (805) 566-6200 

Fax: (805) 566-6385 

Web: http://www.metatools.com 



EoQine EoQine 



Number Nine Visual Technology 
announced its 128- bit graphics accelera- 
tor, Imagine 128 Series 2. Imagine 128 
Series 2 has a built-in 256-bit video 
engine and is capable of speedy genera- 
tion of G ouraud- shaded lines and trian- 
gles, Z buffering, spatial blending, and 
decal-mode texture mapping. It can 



UPGRADE 



VOURSI 



• You've seen Electric Image 
in things like Congo, The 
Net, Batman Forever, J uras- 
sic Park, and Star Trek. 
You've seen what it can do 
in many of your favorite 
games. You've even seen it 
in action in those Intel com- 
mercials (you know, the 
ones with the flying Pen- 
tiums and dolphins?). Well 
now Electric Image has 
released Electric Image 
2.5.2. PICT and QuickTime 
files can be used as maps 
with the newest version. 
Electric Image lets animators 
finesse Inverse Kinematics 
animation and render direct- 
ly into the Quicktime anima- 
tion codec format. It costs 
$990 to upgrade from ver- 
sion 2.0 to 2.5.2 and $495 to 
upgrade from 2.1. to 2.5.2. If 
you are buying it for the first 
time, 2.5.2 costs $7,495. 



• Fractal Design announced 
the newest version of its 
image editor. Painter 4. 
Designers can now blend 
raster and vector imagery 
and collaborate on artwork 
over LANs and the Internet. 
It works with Photoshop, 
Illustrator, and Freehand. It 
runs on Windows and Mac- 
intosh and costs $549. 



handle three operand bit bits at two 
operand speeds and has a hardware D I B 
engine. I magine 128 Series 2 costs $399. 
■ For more information contact: 

Number Nine Visual Technology 

18 Hartwell Ave. 

Lexington, Mass. 02173 

Tel: (617) 674-0009 

Fax: (617) 674-2919 

D laneAnderson ismanaging editor of 
Game Developer. Contact her at diander- 
son@mfi.ODm. 
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BEHIND THE SCREEN 



to the 
(Floating) Point 



Chris Hecker 

Question: Is floofing- 
poini mofh inherently 
evil? flnsuier: Noybe 
noUffhe insfruclion 
timings of modern 
chips ore to be 



believed. Question: But 



ore they to be 
believed? 



When I sat down to write 
this article, it was supposed 
to be the last installment in 
our epic perspective texture 
mapping series. Part of the 
way through, I realized I 
needed to cover what 
ended up as the actual topic 
of this article— floating-point optimiza- 
tions—to complete the optimizations on 
the perspective texture mapper's inner 
loop. So we'll learn some generally cool 
tricks today and apply them to the tex- 
ture mapper in the next issue. In fact, 
these techniques are applicable to any 
high-performance application that mixes 
floating-point and integer math on mod- 
ern processors. Of course, that's a long 
and drawn-out way of saying the tech- 
niques are eminently suitable to cool 
games, whether they texture map or not. 

The Real Story 

A few years ago, you couldn't have 
described a game as an "application that 
mixes floating-point and integer math," 
because no games used floating-point. I n 
fact, floating-point has been synonymous 
with slowness since the beginning of the 
personal computer, when you had to go 
out to the store, buy a floating-point 
coprocessor, and stick it into a socket in 
your motherboard by hand. It's not that 
game developers didn't want to use real 
arithmetic, but the original PCs had 
enough trouble with integer math, let 
alone dealing with the added complexi- 
ties of floating-point. 

W e don't have enough space to 
cover much of the history behind the 
transition from integer math, through 
rational (Bresenham's line-drawing 



algorithm, for example) and fixed- point 
arithmetic, and finally to floating-point, 
but here's the quick summary: For a 
long time, game developers only used 
floating-point math in prototype algo- 
rithms written in high-level languages. 
nee prototyped, the programmers usu- 
ally dropped the code down into fixed- 
point for speed. T hese days, as we'll see, 
floating-point math has caught up with 
integer and fixed-point in terms of 
speed and in some ways has even sur- 
passed it. 

To see why, let's look at the cycle 
timings of the most common mathe- 
matical operations used by game devel- 
opers (addition, subtraction, multiplica- 
tion, and— hopefully relatively rarely— 
division) for fixed- point, integer, and 
floating-point. Table 1 shows the cycles 
times on three generations of Intel 
processors, the PowerPC 604, and a 
modern M I PS. W e see that the float- 
ing-point operations, with the exception 
of additions and subtractions, are actual- 
ly faster than their integer counterparts 
on the modern processors (the 386, a 
decidedly nonmodern processor without 
an integrated floating-point unit, lags 
far behind, and the transitional 486 has 
mixed results). 

Of course, these numbers alone 
don't tell the whole story. T he table 
doesn't show that, although the cycle 
times are still slow compared to single- 
cycle instructions like integer addition, 
you can usually execute other integer 
instructions while the longer floating- 
point operations are running. The 
amount of cycle overlap varies from 
processor to processor, but on really 
long instructions, like floating-point 
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Table 1. Various Instruction limings (Parentheses Indicate Single Precision) 





Integer 


Float 


Integer 


Float 


Integer 


Float 




Add/ Subtract 


Add/Subtract 


Multiply 


Multiply 


Divide 


Divide 


Intel 386/387 


2 


23-34 


9-38 


27-35 


43 


89 


Intel i486 


1 


10 


12-42 


11 


43 


62 (35) 


Intel Pentium 


1 


3 


10 


3 


46 


33 (19) 


PowerPC 604 


1 


3 


4 


3 


20 


31(18) 


MIPS R4x00 


1 


4 


10 


8(7) 


69 


36 (23) 



division, you can usually overlap all but a 
few cycles with other integer (and some- 
times even floating-point) instructions. 
In contrast, the longer integer instruc- 
tions allow no overlap on the current 
Intel processors and limited overlap on 
the other processors. 

On the other hand, the floating- 
point operations are not quite as fast as 
T able 1 implies because you have to load 
the operands into the floating-point unit 
to operate on them, and floating-point 
loads and stores are usually slower than 
their integer counterparts. Worse yet, 
the instructions to convert floating-point 
numbers to integers are even slower still. 
In fact, the overhead of loading, storing, 
and converting floating-point numbers is 
enough to bias the speed advantage 
towards fixed- point on the 486, even 
though the floating-point instruction 
timings for the actual mathematical 
operations are faster than the corre- 
sponding integer operations. 

Today, however, the decreased 
cycle counts combined with the tricl<s 
and techniques we'll cover in this article 
give floating-point math the definite 
speed advantage for some operations, 
and the combination of floating-point 
and fixed- point math is unbeatable. 

If It Ain't Float, Don't Fix It 

A s usual, I 'm going to have to assume you 
l<now how fixed- point numbers work for 
this discussion. M athematically speal<ing, 
a fixed-point number is an integer created 
by multiplying a real number by a con- 
stant positive integer scale and removing 
the remaining fractional part. This scale 
creates an integer that has a portion of the 
original real number's fraction encoded in 
its least significant bits. This is why fixed- 
point was the real number system of 



choice for so many years; as long as we're 
consistent with our scales, we can use fast 
integer operations and it just worl<s, with 
a few caveats. It has big problems with 
range and is a mess to deal with, for the 
most part. You need to be very careful to 
avoid overflow and underflow with fixed- 
point numbers, and those "fast" integer 
operations aren't as fast as the same float- 
ing-point operations anymore. 

Floating-point math, on the other 
hand, is a breeze to worl< with. T he main 
idea behind floating-point is to trade 
some bits of precision for a lot of range. 

For the moment, let's forget about 
floating-point numbers and imagine we 
have really huge binary fixed- point num- 
bers, with lots of bits on the integer and 
fractional sides of our binary point. Say 
we have 1,000 bits on each side, so we 
can represent numbers as large as 2^°°° 
and as small as 2™". This hypothetical 
fixed- point format has a huge range and 
a lot of precision, where range is defined 
as the ratio between the largest and the 
smallest representable number, and pre- 
cision is defined as how many significant 
digits (or bits) the representation has. 
So, for example, when we're dealing with 
incredibly huge numbers in our galaxy 
simulator, we can still l<eep the celestial 
distances accurate to within subatomic 
particle radii. 

H owever, most applications don't 
need anywhere near that much precision. 
M any applications need the range to rep- 
resent huge values lil<e distances between 
stars or tiny values like the distance 
between atoms, but they don't often need 
to represent values from one scale when 
dealing with values of the other. 

Floating-point numbers take 
advantage of this discrepency between 
precision and range to store numbers 



with a very large range (even greater 
than our hypothetical 2,000- bit fixed- 
point number, in fact) in very few bits. 
T hey do this by storing the real number's 
exponent separately from its mantissa, 
just like scientific notation. In scientific 
notation, a number like 2.345 x 10^^ has 
a mantissa of 2.345 and an exponent of 
35 (sometimes you'll see the terms sig- 
nificand and characteristic instead of 
mantissa and exponent, but they're syn- 
onymous). This number is only precise 
to four significant digits, but its expo- 
nent is quite big (imagine moving the 
decimal point 35 places to the right and 
adding zeros after the mantissa runs out 
of significant digits). 

The way the precision scales with 
the magnitude of the value is the other 
important thing. When the exponent is 
35, incrementing the first digit changes 
the value by 10^^ but when the exponent 
is 0, incrementing the first digit only 
changes the value by 1. This way you get 
angstrom accuracy when you're on the 
scale of angstroms, but not when you're 
on the scale of galaxies (when you really 
don't need it). 

The IEEE floating-point standard 
specifies floating-point representations 
and how operations on those representa- 
tions behave. T he two IEEE floating- 
point formats we care about are "single" 
and "double" precision. They both share 
the same equation for conversion from 
the binary floating-point representation 
to the real number representation, and 
you'll recognize it as a binary form of sci- 
entific notation: 

-r^"x2'''°™'-""xl.mantis5a (1) 

The only differences between the two 
formats are the widths of some of the 
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named fields in Equation 1, so we'll go 
over each part of it in turn and point out 
the differences when they pop up. 

We'll start on the right-hand side 
of Equation 1. The mantissa expression 
(the 1. mantissa part of the equation) is 
somewhat strange when you first lool< at 
it, but it becomes a little clearer when 
you realize that mantissa is a binary 
number. It's also important to realize 
that it is a normalized, binary number. 
"Normalized" for scientific numbers 
means the mantissa is always greater 



based on a positive or negative exponent, 
respectively. T his is exactly analogous to 
the base- 10 decimal scientific notation, 
where the exponent shifts the decimal 
point right or left, inserting zeros as nec- 
essary. The exponent field is the l<ey to 
the range advantage floating-point num- 
bers have over fixed-point numbers of 
the same bit width. W hile a fixed- point 
number has an implicit binary point and 
all the bits are, in essence, a mantissa, a 
floating-point number reserves an expo- 
nent field to shift the binary point 



yields an unbiased exponent of 127. 
Exponent values of all Os and all Is are 
reserved for special numerical situations, 
lil<e infinity and zero, but we don't have 
space to cover them. 

Finally, the sign bit dictates 
whether the number is positive or nega- 
tive. U nlil<e two's complement represen- 
tations, floating-point numbers that dif- 
fer only in sign also differ only in their 
sign bit. We'll discuss the implications of 
this further. Table 2 contains the field 
sizes for single and double precision 



mantissa 




than or equal to 1 and less than 10 (in 
other words, a single, non-zero digit). 
ur previous example of scientific nota- 
tion, 2.345 X 10^^, is normalized, while 
the same number represented as 234,500 
X 10^° is not. W hen a binary number is 
normalized, it is shifted until the most 
significant bit isl. Think about thisfor a 
second (I had to). If there are leading 
zeros in the binary number, we can rep- 
resent them as part of the exponent, just 
as if there are leading digits in our dec- 
imal scientific notation. And because the 
most significant bit is always 1, we can 
avoid storing it altogether and make it 
implicit in our representation. So, just 
like normalized decimal scientific nota- 
tion keeps its mantissa between 1 and 
10, the binary mantissa in a floating- 
point number is always greater than or 
equal to 1 and less than 2 (if we include 
the implicit leading 1). 

Next in line, the exponent expres- 
sion shifts the binary point right or left 



around (hence the term, "floating- 
point"). It's clear that 8 bits reserved for 
an exponent from a 32- bit word allows a 
range from about 2^" to 2"-^", while the 
best a fixed-point number could do 
would be a 32- bit range, for example 
to 0, 2^^ to 2-", or to 2"^^ but not all 
at the same time. H owever, there's no 
such thing as a free lunch; the 32-bit 
fixed-point number actually has better 
precision than the floating-point num- 
ber, because the fixed- point number has 
32 significant bits, while the floating- 
point number only has 24 significant bits 
left after the exponent is reserved. 

You'll notice the exponent expres- 
sion is actually exponent - bias. T he bias 
is a value set so that the actual bits of the 
exponent field are always positive. In 
other words, assuming the exponent is 8 
bits and the bias is 127, if you want your 
unbiased exponent to be -126 you set 
your biased exponent bits to 1. Likewise, 
a biased exponent field value of 254 





IEEE floating-point values, and Figure 
1 shows their layout, with the sign 
always at the most significant bit. 

An Example 

Let's run through an example by con- 
verting a decimal number into a single 
precision, binary, floating-point number. 
W e'll use the number 8.75 because it's 
easy enough to do by hand, but it still 
shows the important points. First, we 
turn it into a binary fixed- point number, 
1000.11, by figuring out which binary 
bit positions are 1 and 0. Remember, the 
bit positions to the right of the binary 
point go 2"\ 2"^, 2"^, and so on. It 
should be clear that I chose .75 for the 
fractional part because it's 2"^ -i-2 ^ so 
it's easy to calculate. N ext, we shift the 
binary point three positions to the left to 
normalize the number, giving us 1.00011 
X 2l Finally, we bias this exponent by 
adding 127 for the single precision case, 
leaving us with 130 (or 10000010 bina- 
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Figure 2. 8.75 As a IEEE Single Precision Value 




31 30 23 22 

ry) for our biased exponent and 1.00011 
for our mantissa. The leading 1 is 
implicit, as we've already discussed, and 
our number is positive, so the sign bit is 
0. The final floating-point number's bit 
representation is shown in Figure 2. 

N ow that we're familiar with float- 
ing-point numbers and their representa- 
tions, let's learn some tricks. 

Conversions 

I mentioned that on some processors 
the floating-point to integer conver- 
sions are pretty slow, and I wasn't exag- 
gerating. On the Pentium, the instruc- 
tion to store a float as an int, fist, takes 
six cycles. Compare that to a multiply, 
which only takes three, and you see 
what I mean. Worse yet, the FIST 
instruction stalls the floating-point 
pipeline and both integer pipelines, so 
no other instructions can execute until 
the store is finished. H owever, there is 
an alternative, if we put some of the 
floating-point knowledge we've learned 
to use and build our own version of FIST 
using a normal floating-point addition. 

In order to add two floating-point 
numbers together, the C PU needs to 
line up the binary points before doing 
the operation; it can't add the mantissas 
together until they're the same magni- 
tude. This "lining up" basically amounts 
to a left shift of the smaller number's 
binary point by the difference in the two 
exponents. For example, if we want to 
add 2.345 x 10^^ to 1.0 x 10^^ in decimal 
scientific notation, we shift the smaller 
value's decimal point 3 places to the left 
until the numbers are the same magni- 
tude, and do the calculation: 2.345 x 
10^^ + 0.001 X 10^^ = 2.346 x 10^^ B i na- 
ry floating-point works in the same way. 

W e can take advantage of this 
alignment shift to change the bit repre- 
sentation of a floating-point number 





until it's the same as an integer's bit 
representation, and then we can just 
read it like a normal integer. T he key to 
understanding this is to realize that the 
integer value we want is actually in the 
floating-point bits, but it's been nor- 
malized, so it's shifted up to its leading 
1 bit in the mantissa field. Take 8.75, as 
shown in Figure 2. T he integer 8 part is 
the implicit 1 bit and the three leading 
Os in the mantissa. T he following 11 in 
the mantissa is .75 in binary fractional 
bits, just waiting to be turned into a 
fixed-point number. 

I magine what happens when we 
add a power-of-two floating-point 
number, like 2^=256, to 8.75, as in Fig- 



Total 

Width Sign iviantissa 

Single 32 bits 1 bit 23 bits 

Double 64 bits 1 bit 52 bits 



ure 3. I n order to add the numbers, the 
CPU shifts the 8.75 binary point left by 
the difference in the exponents (8 - 3 = 
5, in this example), and then completes 
the addition. The addition itself takes 
the implicit 1 bit in the 256 value and 
adds it to the newly aligned 8.75, and 
when the result is normalized again the 
implicit 1 from the 256 is still in the 
implicit 1-bit place, so the 8.75 stays 
shifted down. You can see it in the 
middle of the mantissa of the result in 
F igure 3. W hat happens if we add in 
223, or the width of the mantissa? As 
you'd expect, the 8.75 mantissa is shift- 
ed down by 23 - 3 =20, leaving just the 
1,000 for the 8 (because we shifted .75 
off the end of the single precision man- 
tissa, the rounding mode will come into 



play, but let's assume we're truncating 
towards zero). If we read in the result- 
ing single precision value as an integer 
and mask off the exponent and sign bit, 
we get the original 8.75 floating-point 
value converted to an integer 8! 

T his trick works for positive num- 
bers, but if you try to convert a negative 
number it will fail. You can see why by 
doing the aligned operation by hand. I 
find it easier to work by subtracting two 
positive numbers than by adding a posi- 
tive and a negative. Instead of 2^^ -i- (- 
8.75), I think of 2" - 8.75. The single 
sign bit representation lends itself to 
this as well (using a piece of paper and a 
pen will really help you see this in 
action). So, when we do the aligned 
subtraction, the 8.75 subtracts from the 
large value's mantissa, and since that's 
all Os (it's a power-of-two), the subtract 
borrows from the implicit 1 bit. This 
seems fine at first, and the mantissa is 
the correct value of -8.75 (shifted 
down), but the normalization step 
screws it up because now that we've 



Bias 

Exponent Value 

8 bits -H27 
11 bits -H023 



borrowed from the implicit 1 bit, it's no 
longer the most significant bit, so the 
normalization shifts everything up by 
one and ruins our integer. 

But wait, all is not lost. All we 
need is a single bit from which to bor- 
row in the mantissa field of the big 
number so that the subtraction will 
leave the implicit 1 bit alone and our 
number will stay shifted. We can get 
this 1 bit simply by multiplying our 
large number by 1.5. 1.5 in binary is 
1.1, and the first 1 becomes the implic- 
it 1 bit, and the second becomes the 
most significant bit of the mantissa, 
ready to be used for borrowing. Now 
negative and positive numbers will stay 
shifted after their normalization. The 
masking for negative numbers amounts 



Table 2. Floating-Point Field Widths and Parameters 
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to filling in the top bits with 1 to com- 
plete the two's-complement integer 
representation. 

The need to masl< for positive and 
negative values is bad enough when you 
are only dealing with one or the other, 
but if you want to transparently deal 
with either, figuring out how to masl< 
the upper bits can be slow. H owever, 
there's a tricl< for this as well. If you 
subtract the integer representation of 
our large, floating-point shift number 
(in other words, treat its bits lil<e an 
integer instead of a float) from the inte- 
ger representation of the number we 
just converted, it will remove all the 
high bits properly for both types of 
numbers, making the bits equal zero for 
positive values and filling them in with 
ones for negative values. 

You'll notice that this technique 
applied to single precision values can 
only use a portion of the full 32 bits 
because the exponent and sign bits are 
in the way. Also, when we use the 1.5 
trick we lose another bit to ensure both 
positive and negative numbers work. 
H owever, we can avoid the range prob- 
lems and avoid masking as well by using 
a double precision number as our con- 
version temporary. If we add our num- 
ber as a double (making sure we use the 
bigger shift value— 2^^ x 1.5 for integer 



truncation) and only read in the least 
significant 32 bits as an integer, we get 
a full 32 bits of precision and we don't 
need to mask, because the exponent and 
sign bits are way up in the second 32 
bits of the double precision value. 

I n summary, we can control the shift 
amount by using the exponent of a large 
number added to the value we want to 
convert. W e can shift all the way down to 
integer truncation, or we can shift part of 
the way down and preserve some frac- 
tional precision in fixed-point. 

This seems like a lot of trouble, 
but on some processors with slow con- 
version functions, like the x86 family, it 
can make a difference. On the Pentium 
with FIST you have to wait for six cycles 
before you can execute any other 
instructions. But using the addition 
trick, you can insert three cycles worth 
of integer instructions between the add 
and the store. You can also control how 
many bits of fractional precision you 
keep, instead of always converting to an 
integer. 

Whaf s Your Sign? 

Before I wrap this up, I'd like to throw 
out some other techniques to get you 
thinking. 

T he exponent bias is there for a rea- 
son: comparing. Because the exponents 



are always positive (and are in more sig- 
nificant bits than the mantissa), large 
numbers compare greater than small 
numbers even when the floating-point 
values are compared as normal integer 
bits. The sign bit throws a monkey 
wrench in this, but it works great for sin- 
gle-signed values. Of course, you can take 
the absolute value of a floating-point 
number by masking off the sign bit. 

I've already hinted at the coolest 
trick— overlapping integer instructions 
while doing lengthy divides— but I 
haven't gone into detail on it. It will 
have to wait until next time, when we'll 
discuss this in depth. 

Two people introduced me to the 
various tricks in this article and got me 
interested in the details of floating- 
point arithmetic. Terje M athisen at 
N orsk H ydro first showed me the con- 
version trick, and Sean Barrett from 
L ooking G lass T echnologies made it 
work on negative numbers. 

If you want to learn more about 
floating-point, TheArt of Computer Pro- 
gramming, Vol. 2: Seminumerical Algo- 
rithms (Addison-W esley, 1981) by D . 
Knuth is a good source for the theory. 
M ost CPU programming manuals have 
fairly detailed descriptions as well. You 
can get Adobe Portable Document For- 
mat versions of the PowerPC manuals on 
http://www.mot.com. If you really want 
to understand floating-point and its 
implications for numerical programming, 
you'll want to pick up a numerical analysis 
textbook that deals with computers. 

You also might want to look at the 
Graphics Gems series from AP Profes- 
sional. The series covers a number of 
floating-point tricks like the ones dis- 
cussed here. A good example calculates a 
quick and dirty square root by halving 
the exponent and looking up the first 
few bits of the mantissa in a table. 
Another takes advantage of the format 
to do quick absolute values and compares 
for clipping outcode generation. Once 
you understand the floating-point for- 
mat, you can come up with all sorts of 
tricksof your own. ■ 

Chris H ed<er tries to stay normalized, 
buthecan be biased at died<er@bix.a3m. 
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Using Genet:ic 
Algori-tlims t:o Evolve 
Computer Opponen-ts 




Using OID, you can program a simple genetic aigoritlim tliat wiii evoive into a reasonably 
intelligent computer opponent that doesn't resort to cheating to stay in the game. 



I love a good strategy game. I've 
spent uncountable hours playing 
C ivilization and M aster of rion. 
But I find I keep going back to my 
ancient Diplomacy (CG A yet!) and 
Risk programs with their klunky 
and awkward user interfaces 
because, as far as I can tell, they 
aren't "cheating" to play a good game. 

To be fair, if computer strategy 
games had to play by the same rules, 
these games might still be in develop- 
ment or possibly never even started, and 
I certainly wouldn't want that. I'm sure 
I'll keep playing both games and others 



that cheat too. But whenever I think of 
buying new games, part of my evaluation 
includes trying to determine whether 
and how much they might have to cheat 
to be challenging. 

One way to have a new strategy 
game that played fair was to write my 
own, so I set off to do just that. H oping 
to have strong computer players without 
having to spend weeks or months writing 
them, I looked for a way to let my com- 
puter generate them with spare CPU 
cycles. 

T his article is a description of how I 
designed a game that could use genetic 
algorithms to generate some decent com- 
puter players. Although the computer 
players do not have access to all the infor- 
mation human players have, I have 
evolved some that can beat me in an 
evenly matched game— without cheating! 

First, I'll outline the game, dis- 
cussing the major design issues. I n fact, 
there are many different rule options that 
can be selected when designing a sce- 
nario, so the rules I do mention will be 
the default rules in the basic game. 
Then, I'll show how the design supports 
computer players with a very small 
"genetic" program, along with some 
examples. T hen, I 'II show how easy it is 
to evolve these programs and how to test 
whether they really improve over time. 

Currently, a very high interest in 
genetic algorithms exists, and it is get- 
ting easier to find articles and books on 
the subject with many examples and 
details. (If you have W eb access, just do 
a search for genetic algorithms!) U nfor- 
tunately, very few genetic algorithm 
applications I've seen actually do any- 
thing interesting from a games perspec- 
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tive. H ere, I'll try to concentrate on the 
design of "something interesting" to do 
with genetic algorithms and minimize 
the tutorial and theoretical aspects. 

A Description of Cioaic, 
Dagger, and DNA 

T he game is lil<e a cross between D iplo- 
macy and Stratego with a few mutations 
thrown in. The playing field is a map 
divided into areas, some of which con- 
tain factories. The factories are needed 
to support the armies that are used to 
capture more areas. E ach turn, a factory 
supports one army or spy or puts one 
credit in the player's treasury that can be 
spent later. All players' armies and spies 
are moved simultaneously, so a turn con- 
sists of submitting a set of orders, not 
actually moving pieces. 

The legality of moving pieces is 
based solely on the current position, so if 
you are legally able to construct an order, 
it will always be carried out. W hat you 
won't necessarily know until the next 
turn is how many of your armies sur- 
vived in each area and who ended up 
controlling each area and any factories in 
it. W hen all players are ready, the game 
engine reads the human players' orders, 
generates the orders for the computer 
players, performs all moves, and resolves 
combat in areas where armies are owned 
by more than one player. 

In the entire design, the combat 
resolution rules have seen the most revi- 
sions. M y design goals for combat were: 
fair, simple, and repeatable. I have seen 
fair and repeatable with Diplomacy, 
which does those very well with no dice 
rolls. But if you've ever played noncom- 
puter Diplomacy, you know how com- 



plicated resolving all the players' orders 
can get, as one set of orders very often 
prohibits another set from being carried 
out. T he dependencies can be recursive, 
so it is not simple. 

I n my game, all legal orders are car- 
ried out, thus any pieces ordered built are 
placed on the map, and all pieces with 
orders to move are moved with no excep- 
tions. Combat is then resolved in each 
area that contains armies belonging to 
more than one player (spies are not 
involved in combat). Combat does not 
necessarily result in only one player 
remaining in an area, in fact all four play- 
ers can have one army each in a given 
area, and nothing will happen. H owever, 
armies in an area that contains other 
armies may only be ordered to leave that 
area if they move to another area already 
controlled by the owning player. 

Each players' combat losses are 
computed separately, but in parallel, and 
are based on the number of armies the 
player has, the number of armies the sin- 
gle largest opposing player has, and who, 
if anyone, previously controlled the area 
being contested. A player in an area he 
or she controls loses one army for every 
three attacking armies in the largest 
opposing force. In an area he or she 
does not control, the player loses one 
army for every two armies in the largest 
opposing force. After combat, if only 
one player has surviving armies in an 
area, that player gains control of that 
area and any factories in it. 

A player only knows about the 
other players' forces upon encountering 
them, which can be done intentionally 
by sending spies off into enemy territory. 
A player's map does show all the facto- 
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Figure lA. A Simple Game Map 
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ries in the game, but not necessarily who 
controls them. 

W hen a game is over, each player 
scores from to 100, being the percent- 
age of all factories in the game he or she 
controls. There are early win cases 
where one player can score all the 100 
points. The actual scoring method is not 
important, as long as there is some rela- 
tive fitness evaluation available to the 
genetic algorithm code. 

Computer Player 
Genetic Codes 

Inspired by Tom Ray'sTierra machine, I 
decided that the bits in the computer 
player genetic codes would be interpret- 
ed lil<e machine code instructions. 
H owever, unlil<e the Tierra machine, a 
program that can mal<e copies of itself 
isn't lil<ely to be very similar to one that 
can play a strategy game. Intending to 
spend as little time as possible writing 
the initial opponents, I tried to design a 
fairly powerful virtual machine that 
would implement a simple computer 



opponent language. I call this the 1 D , 
which stands for Opponent Implemen- 
tation D evice. 

It is also convenient that the suffix 
"old" is used to mean an imperfect 
resemblance, since ultimately what we 
are doing when writing computer players 
is creating an imperfect resemblance of a 
live human opponent. I wanted the 1 D 
language to let me write a few simple 
seed programs with a small number of 
instructions that could play a game, even 
if poorly, and hoped that evolution 
would do the rest. 

T he 1 D language consists of a set 
of instructions that do not directly move 
individual pieces, but instead assign val- 
ues to map areas and playing pieces. 
These values are used to decide which 
pieces, if any, move where. You can 
thinl< of the map values as elevations and 
the pieces as marbles where their values 
are heights. W ith the right instructions, 
each marble on the map can add its 
height to the elevation of the area the 
marble is in. A single instruction can 



modify a register in each area on the 
map. For example, the instruction Add 
Rl my Army will add the number of the 
players armies, if any, to the Rl register 
in each map area. 

nee a sequence of instructions has 
generated elevations on the map, a single 
move instruction can query all pieces 
individually to see if any want to "roll 
downhill" into adjacent areas. Any that 
do are given orders to move. W henever 
a piece is given these orders, its height is 
used to reduce the elevation of the area it 
will leave and increase the elevation of 
the area it will enter before the next 
piece is queried. 

For example, imagine that all areas 
with an enemy factory are assigned a low 
elevation, say, the number of factories as 
a negative number, and all areas with 
your armies are assigned a high eleva- 
tion, say, the number of armies as a posi- 
tive number. The Hove instruction will 
then query all your armies to see if any 
are adjacent to areas with lower eleva- 
tions, which will include empty areas 
next to areas with armies and, most 
importantly, adjacent enemy factories. 

Building new pieces is similar, the 
Build instruction builds new pieces at 
factories at the lowest elevations first, 
adding the height of the piece each time, 
surplus treasury, and other thresholds 
permitting. 

T he following tiny 1 D program 
can play a game, although not very well. 
Yes, that is really all the code needed! If 
the other players do nothing each turn, 
this program will eventually take over 
most of the map in the basic game: 

Sub Rl notmy Factory 
Add Rl my Army 
Build Army 1 
Move Army 1 
Halt 

First, let's explore the architecture 
and environment. Then, we'll, step 
through this program line by line to see 
what it does in more detail. 

The OID Architecture 

TheOID language has no loops or 
branching; all programs start at the 
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beginning and run to the end. All 1 D 
programs have an (arbitrary) maximum 
of 25 instructions, including the Halt 
required at the end. If an instruction in 
the program does not specifically gener- 
ate an order for a given piece, the default 
orders for that piece are to defend, which 
isthe same as doing nothing. 

A program generated randomly in 
this language is guaranteed not to crash 
or cause any other l<ind of harm and to 
terminate in a finite time. T his is neces- 
sary so that the genetic algorithms can 
"cross" and "mutate" programs without 
regard to the validity of the instructions 
or sequences of instructions. If a pro- 
gram does not generate any meaningful 
orders for a player, the pieces will just sit 
and defend until the end of the game or 
until they are destroyed by other players. 
The worst thing a program can do is dis- 
band all its armies and leave its factories 
undefended. A program only considers 
one turn in isolation. There is no provi- 
sion to store information to be used in a 
later turn or keep tracl< of what an oppo- 
nent is doing overtime. 

The Area Registers 

T here are four signed integer registers for 
each area in the game: RO, Rl, R2, and R3. 
These have independent values in each 
area and are processed (virtually) in paral- 
lel. For example, the instruction Add R3 
my Factory inspects each area, and, if the 
area contains factories owned by the 
player running the OID program, each 
area has the number of factories in that 
area added to the area's R3 register. T he 
R3 registers in all other areas have zero 
added to them and remain unchanged. 

At every program start, area register 
RO is 1 for all areas, and Rl, R2, and R3 are 
for all areas. M ost instructions that 
can change Rl are conditional on the 
value of RO in the same area being 
greater than zero. Thus, for most 
instructions, if RO is or negative in a 
given area, an instruction that modifies 
Rl would be skipped for that area. In 
any other area where RO is greater than 
zero, the instruction modifying Rl would 
be executed. R2 and R3 are general pur- 
pose area registers and have no special 
restrictions. 



Figure IB. The First Turn of the Game 




OID Program Walk-Through 

N ow let's take our sample program 
above, line by line. We will consider the 
game map in Figure lA and assume we 
are running the OID program for the 
Red player. Figure IB shows the first 
turn of a game after running the pro- 
gram. The pieces that have been 
ordered to move are shown with arrows 
indicating their moves. 

L isting 1 shows the debug output 
produced by the OID when it runs a 
program, showing each instruction as it 
is encountered and showing a register set 
after any instruction that might modify 
that register. I n this particular example, 
the numbers have been formatted in a 
three- by- three matrix to positionally 
match the areas they represent on the 
game map. 

Since we know the program starts 
with all RO registers set to 1 and RO is not 
changed anywhere, all instructions in 
this program that operate on Rl registers 
will be performed. Also, all Rl registers 
will be initialized to 0. 



The first line. Sub Rl notmy Factory, 
will subtract the number of enemy or 
unowned factories in each area from that 



Listing 1. Debug Output 



Turn 1 

Sub Rl notmy Factory 
Rl contains: 

-3 
0-5 
-3 -10 

Add Rl my Army 
Rl contains: 

10 -3 

0-5 

-3 -10 
Build Army 1 

built=0 
Move Army 1 
moved=8 
Rl contains: 

2 1 -3 

1 1 
-3 -10 

Halt 
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Figure 2A. Red's Position Following Turn 2 




Listing 2. Turn 2 


Turn 2 




Sub Rl notmy Factory 


Rl contains: 







-3 








-3 


-10 


Add Rl my Army 


Rl contains: 




2 1 


-3 


1 6 





-3 


-10 


Build Army 1 




built=5 




Rl contains: 




7 1 


-3 


1 6 





-3 


-10 


Move Army 1 




moved=7 




Rl contains: 




5 2 


-3 


2 1 


1 


1 


-10 


Halt 





area's Rl register. After the Sub Rl notmy 
Factory instruction, you can see the neg- 
ative values of all non-Red owned facto- 
ries in the game. The factory in the 
upper left is already owned by the Red 
player and does not qualify as a notmy 
Factory, leaving the upper left Rl register 
unchanged. 

After the Add Rl my Army instruc- 
tion, the upper left Rl register contains 
10, since Red has 10 armies in upper left 
area. N o other registers are changed. 

The Build instruction needs a little 
more explanation. T here are some other 
specific purpose registers that are used by 
the Build and Disband instructions, relat- 
ing to the players' current cash flow and 
treasury situation. Unfortunately, they 
are one of the weaker aspects of this 
design, as they don't provide much flexi- 
bility to make decisions about the rela- 
tive proportions of armies and spies or to 
change these proportions under different 
circumstances. T hey, like the area regis- 
ters, are initialized to at program start. 
If we don't change them, the Build 



instruction will default to building exact- 
ly enough armies to make the Army and 
Factory totals the same. 

The Build Army 1 instruction does 
nothing, since Red currently has 10 
armies and 10 factories. 

The Build and Mo«e instructions do 
not have a register field and always use 
the Rl register. The Move instruction 
essentially queries all unordered armies 
one by one to see if any want to move. 
M ore specifically, it sorts all areas with 
unordered armies by elevation and, start- 
ing with the highest elevations and 
working down, determines whether an 
army should move. 

First it removes the armies height 
from that area's Rl register and looks for 
an adjacent area with the lowest eleva- 
tion. If the lowest adjacent area is lower 
that the origin area, the army is given 
orders to move to the adjacent area, and 
the adjacent area's Rl register is 
increased by the army's height. The 
adjacent area is immediately repositioned 
in the Move's sort list if necessary, and, if 
there are still unordered armies in the 
origin area, the next army is considered. 
If an army is not moved, its height is 
added back to the Rl register of its area 
of origin, and the Move instruction pro- 
ceeds to the next area in the list. 

Now, the Move Army 1 instruction 
moves eight armies, and, as you can see 
IntheRl matrix following Move Army 1 in 
L isting 1, it manages to even out the ele- 
vations of the three adjacent areas. T he 
upper left is still one unit higher than its 
neighbors, but since an army subtracts its 
own height before considering a move, 
the last army that was considered for 
moving did not see a lower elevation. 

Following with turn 2, seen in Fig- 
ure 2A, Red has not encountered any 
other players, but has gained the five fac- 
tories in the center of the map. Skipping 
down to the Build Army 1 instruction, we 
see that it will now come into play, as 
Red has more factories than armies. 
L isting 2 shows the 1 D output for turn 
2, and Figure 2B shows the map after 
the run. The Build instruction had to 
build five armies and choose between 
two factories. As you can see in L isting 
2, before the Build instruction, the ele- 
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vation of the upper left factory was 2, 
and the center factory was 6. T he first 
four armies were built at the lowest ele- 
vation factory in the upper left, and for 
the fifth factory a choice had to be made 
because the elevations were equal. 

When given such a choice, my 
implementation always chooses the area 
with the lowest internal index number, 
which in this case is the upper left facto- 
ry. T he advantages are reproducible for 
debugging and fitness testing for the 
genetic selection, since in both cases a 
given game between ID-run players 
will always produce exactly the same 
result. The disadvantages are that on a 
rotationally symmetric board, 1 D play- 
ers will not play symmetrically, and 
when playing against a human, 01 D 
players are very predictable, once you get 
to l<now them and the map. 

As you can see in Figure 2B, this 
Red program does not protect the center 
factory very well. In fact, if the same 
1 D program was playing for a different 
player from a similar start in the lower 
right corner, that player would tal<e the 
center factory from Red on turn 3. 

Applying the 
Genetic Algorithms 

N ow we have a design that may support 
genetic algorithm evolution. After a 
quick review of the genetic algorithm 
technique and some hand- constructed 
examples, I'll try to evolve some new 
players with the 1 D that was con- 
structed with the design outlined here. 

The genetic algorithm technique 
for solving a problem is, simply stated: 

1. Start with a pool of candidate solu- 
tions. 

2. Evaluatethefitnessof each solution. 

3. Replace some solutions with combi- 
nations of others. 

4. Possibly make random modifications 
to the newly created solutions. 

5. G to step 2. 

W ith the proper fitness function for 
step 2, selection criteria for step 3, and 
mutation rate in step 4, your pool of 
solutions should improve as this process 
iterates. 

Generating an initial pool of OID 
programs is, by design, reasonably sim- 



ple. They don't have to be good, but 
they have to play well enough that if we 
put them in a game they would do better 
than just sitting in their initial positions. 
W e have seen this program play well 
enough for this. 

I n this implementation, we can only 
evaluate relative fitnesses of the 1 D 
programs. To do that, they must play 
against each other. T he scoring system I 
use can be thought of as food for the 
programs. T he programs consume a set 



amount of food to enter a tournament, 
and the winners are rewarded with more 
food. After a number of games, the food 
will be roughly proportional to the rela- 
tive fitness of a program, and when a 
program's food supply goes below zero, 
it becomes a candidate for replacement. 

T he game allows up to four players, 
letting the OID evolution engine evalu- 
ate four players relative to each other at 
one time. T he map in the basic game 
does not necessarily contain starting 
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Figure 2B. The Map after Running OID 




positions of equal fairness, so four games 
are always played as a tournament, with 
the players rotating seats after each 
game. I could have used all 24 possible 
combinations of four players in four 
seats, but it seemed lil<e overkill. After 
each tournament, each participating pro- 
gram receives the average of its scores 
from the four games in food points. 

I wrote the E volution E ngine to 
allow the user to control most things 
that seemed interesting, including: 
• The maximum food a pool member 
can store 



Table 1. First Tournament 



Gene 





1 


2 


3 




Red 


27 








24 


12 


Yellow 


56 


1 


18 





18 


Green 


100 


4 


18 


21 


35 


Blue 


59 





14 


52 


31 


Score 


60 


1 


12 


24 





• H ow much food it costs to enter a 
tournament 

• H ow much food it costs when chosen 
as a parent 

• H ow much food a newly created pool 
member starts with 

• The mutation rate 

• H ow parents are chosen 

• H ow pool members are chosen for 
each tournament. 

There are many possible combina- 
tions of parameters and techniques, 
some more or less efficient than others, 
and some that do not produce useful 
evolution at all. W e could write yet 
another genetic algorithm to evolve an 
efficient parameter set for this one. T he 
description that follows is an extremely 
over-simplified version of what the ID 
does, without worrying too much about 
parameter settings. 

A (Simplified) 
Tournament Walk-through 

Four pool members are chosen to play a 
tournament. I wrote the following four 



programs by hand for this example of 
player evolution: 

// Gene (from above) 
Sub Rl notmy Factory 
Add Rl my Army 
Build Army 1 
Move Army 1 
Halt 

// Gene 1 
Add Rl my Army 
Hul Rl 5 
Bund Army 2 
Move Army 1 
Halt 

// Gene 2 
Distf Rl 
Distf Rl 
Add Rl my Army 
Move Army 5 
Build Army 1 
Halt 

// Gene 3 

Sub Rl notmy Factory 

Aug Rl 1 

Add Rl my Army 

Move Army 1 

Build Army 1 

Halt 

After running a tournament with 
these programs, the results shown in 
T able 1 were produced. This matrix 
shows the gene programs in the columns 
and the seating positions in the rows. 
As you can see in the first column, gene 
O's average score from the four games 
was 60 points. T he results from the four 
individual game scores are placed diago- 
nally in the matrix, so the map positions 
can also be scored in the rows. I use this 
to help me tune the starting positions as 
much as possible for fairness. (Because 
of rounding, scores from any given game 
or tournament will often add up to less 
than 100. So far, no computer players 
have evolved sufficiently to complain.) 

In this particular tournament. Red 
seems to be a weaker position than 
Green, but this minor difference could 
easily change with different players. 
Also, with these numbers, we might do 
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some statistical comparison between the 
seating results in the right most column 
and the gene score results across the 
bottom. 

For example, if the Red position 
won every game played, the tournament 
scores for each gene would be 25, and 
we wouldn't have learned anything 
except to play Red if you want to win. 
You could play around a little with sta- 
tistical analysis in an attempt to evalu- 
ate the significance of any tournament. 
H owever, because we rotate the seati ng 
positions, if a game is not fair, it will 
tend to have only minimal effect on the 
relative fitness comparisons of the 
genes, since they will tend to get very 
similar scores. 

Survival of the Win(est) 

Let's assume that gene 1 needed to win 
more than 1 food point to survive and is 
replaced. TheOID implements gene 
crossing by tal<ing a random number of 
instructions from the beginning of one 
program and concatenating them to a 
random number of instructions from 
the end of another program. The ran- 
dom numbers are chosen, so the result- 
ing program never exceeds the 25 
instruction limit. 

If we choose the new parents from 
the two highest scoring genes, and 3, 
and cross them without mutation, we 
might get the following result: 

Sub Rl notmy Factory // 



Add Rl my Army // 

Build Army 1 // 

Avg Rl 1 // 3 

Add Rl my Army // 3 

Move Army 1 // 3 

Build Army 1 // 3 

Halt // 3 



There is now a redundant Build 
instruction of which, in this particular 
program, the second will never build 
anything. H owever, the interesting 
thing is that some instructions have 
been inserted between a Bund and Move 
instruction. Build and no«e are using 
different elevation maps to mal<e their 
decisions. N one of the original four 
programs does this. 



Let's run another tournament with 
the new gene 1. T he results are shown 
in Table 2. There were no miracles here, 
but the new gene 1 is a definite improve- 
ment over the old. 

Does It Really Work? 

I loaded the original four gene programs 
intotheOID as the first of 50 pool mem- 
bers. I filled the remaining 46 pool 
entries with random crosses and muta- 
tions of the original four. I locl<ed the 
original four so they would not be deleted 
if they ran out of food; they would just 
maintain a negative food supply. Then I 
ran 300 tournaments or 1,200 total games 
on a map that has 24 areas. This tool< 
about 30 minutes on my 486DX2-66. I 
scanned the resulting pool for a gene with 
a high food score and found the following 
program for gene 48: 

Sub Rl notmy Factory 

DistF Rl 

Mul Rl 5 

Add Rl my Army 

Move Army 1 

Build Army 1 

Add Rl my Army 

Build Army 1 

Move Army 1 

Halt 

I noticed that all four original pro- 
grams showed a food supply in the nega- 
tive hundreds. J ust to be sure, I set up a 
tournament with this new program and 
three of the original genes: 0, 2, and 3, 
just to see what would happen. Gene 48 
scored 100 in all four games! 

I played a game as a human with 
the original genes 0, 2, and 3 as the 
opponents, and they were pretty easy to 
beat. I won after just a few turns. Then, 
I played another with gene 48 running 
the other three opponents, and I had to 
work a little bit to win. I n fact, a couple 
of turns tool< quite a bit of thinl<ing, and 
I came close to losing factories more 
than once. For 30 minutes of evolution, 
that's not too bad. 

Seeing the Enemy 

B etween the other users of the I D 
program and me, we've run a little more 



than a million tournaments. M any of 
the newly evolved players can consis- 
tently beat me— that is, until I learn 
what they are doing. The game inter- 
face allows human players to run an 
OID program as an advisor and accept, 
ignore, or modify the orders advised. 
Because I can learn techniques for play- 
ing my game from them, I get a little 
better and can eventually beat the better 
ones more often than not. 

W ith a big enough map, say 50 or 
more areas, which is a little more than a 



Table 2. Second Tournament 



Gene 





1 


2 


3 




Red 


27 


25 


16 


24 


23 


Yellow 


39 


28 


18 


28 


28 


Green 


29 


21 


18 


21 


22 


Blue 


33 


25 


14 


25 


24 


Score 


32 


24 


16 


24 





Risl< map and a little less than D iplo- 
macy, I always seem to mal<e a mistal<e 
somewhere, and the enemy breaks 
through the front lines. This almost 
always leads to unrecoverable disaster- 
even when I use spies, and no 1 D pro- 
gram has evolved to use spies very well. 

All in all, I've got some tough 
opponents, which I didn't have to spend 
weeks or months writing. I don't cheat, 
and occasionally I even feel good about 
it when I lose because, after all, I creat- 
ed them, even if only indirectly. ■ 



Don O'Brien is on a quest for ways to 
make a living and have a life at the same 
time after many long years of PCB CAD 
system design. You can reach him at 
71702. 2255@compu5erve.a)m. 



Tom Ray's Tierra program is 
I described in "An Approach to the 
Synthesis of L ife" (Artificial L ife 1 1 , 
Addison-W esley 1992, pp. 371-408). 
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XSplat 
Revisi 



Figure 1. Ball and Paddle Motion 
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1 Pixel 
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Paddle: 




1 Pixel 49 Pixels 



1 Pixel 



New Position (Draw) 



Old Position (Erase) 



Overlap (Unchanged) 



Witty subject headings and 
an engaging opening line 
stump hundreds of techni- 
cal writers every month. 
T he technical part of an 
article like this comes easi- 
ly; a programmer should be 
able to crank out several 
pages describing a piece of code if he or 
she has thought it through carefully. I t's 
repackaging all that technical drivel into 
human speech that makes the writing 
tough. 

T his month, I hit a wall trying to 
segue from my last X Splat article to 
this one. I wanted to talk about how 
I've presented enough X Splat in the 
last few installments of this series to 
move away from examining multiple 
implementations of the platform-spe- 
cific stuff and toward demonstrating 
the real gold mine of cross- platform 
development— which is, of course, the 



ability to tune code independently of 
the target platform. 

M y girlfriend suggested I start the 
article by telling a few jokes. Relax the 
crowd a bit. Your basic toastmaster type 
of stuff. I thought about trying the 
"three strings walk into a bar... " bit, but 
I think I'll just skip the preamble and 
cut to the chase. 

But before I begin, I should 
remind you that the code for this article 
(and for others in this magazine) is 
available at the Game D a/eloper ftp site, 
which is in ftp://ftp.mfi.com in the 
/pub/gamedev/src directory, or on 
CompuServe in the Game Developer 
L ibrary of SD FORUM . 

XSplat Plumbing 

W e need to look at two things related to 
the framework— they'll fill in a couple of 
gaps before we get started on this 
month's antics. 



34 GAME DEVELOPER • FEBRUARY/MARCH 1996 



I promised to provide a SwapRect 
function to augment the SuapBuffer 
function, which is all we've had until 
now. n both M acintosh and W in- 
dows, this is just a general case of the 
SuapBuffer code, SO 1 11 leave you to 
guess at its implementation or sneal< a 
peek at the Game Developer ftp site. 
T he function prototype looks like this: 

void COffscreenBuffer: :SuapRect(int 
Left, int Top, int Right, int Bottom) 
const; 

H ere's a hint. You can now imple- 
ment COffscreenBuffer:: SuapBuffer as an 
inline call to COffscreenBuffer: :SuapRect 
likethis: 

inline void COffscreenBuffer: :Suap 
Buffer(void) const 

{ 

SuapRect(0, 0, Width, Height); 

} 

SuapRect is bottom- right exclusive, 
meaning that column Right and row Bot- 
tom don't get copied. To swap a single 
pixel (a 1-by-l rectangle), call 
SuapRect(x, y, x+1, y+1) . 

W e're also going to need a func- 
tion to query the system clock. M acin- 
tosh and Windows both provide 
straightforward ways to get this informa- 
tion, so we can just do some simple con- 
ditional compilation. H ere's the function 
we'll use for now: 

inline long unsigned GetHillisecond 
Time (void) 

{ 

#if defined(.WlNDOWS) 



return timeGetTimeO; 

#eUf defined(.HACINTOSH) 

return (long unsigned)TickCount() * 
1000 / 60; 

#endif 
} 

On Windows, timeGetTime returns 
the current value of the multimedia 
timer, in milliseconds. Under Windows 
N T , this function can have latencies 
around 5 to 10 milliseconds, depending 
on the hardware and NT version. The 
solution to this latency problem is to use 
QueryPerformanceCounter, but I'm not 
going to do that right now. U nder W in- 
dows 95, timeGetTime is millisecond accu- 
rate. On the Macintosh, TickCount 
returns the number of ticks since the 
computer started, with one tick being '/eo 
of a second, so it's accurate only to about 
17 milliseconds. 

N ow that we've added these plat- 
form-specific implementations to our 
XSplat repertoire, we can tackle the plat- 
form-independent problem of speeding 
up graphics. I 'II shut up about X Splat for 
the rest of this article. 

Shoveling Dirt 

W atching the sprite move in the sample 
program made me feel like I was watch- 
ing the arrival of the next Ice Age in real 
time. T here aren't many games that 
could be slower: if you played it for too 
long, spiders may have started spinning 
webs across your arms. I promised to 
make it faster, though, and that's what 
I 'm going to do. 



J on Blossom 



Editor'sNote In Part II of this series, 
which appeared in the December 
1995/January 1996 issue, Jon Blossom 
used a simple game format to demon- 
strate his approach to cross- pi atform 
programming that played similarly to 
thedassicAtari video game"Breakout." 
Jon and the E ditors of G ame D evel- 
oper want to remind our readers that 
"Breakout" is a protected trademark 
and copyrighted work of Atari Corp. 
(oDpyright 1983-1996 Atari Corp., all 
rights reserved). U nauthorized use of 
others' code or audiovisual elements 
may constitute a violation of the 
owner's intel I ed:ual property rights. Use 
of the "Breakout" name in Jon's pro- 
gramming exerdsewas not intended, 
and should not be interpreted, as an 
endorsement by G ame D eveloper of 
any unauthorized use of Atari's "Break- 
out" trademark or copyrighted game 
Weregret any misunderstanding. 

The code J on has written for this series 
of articles is now available on the 
Game Developer ftp site ftp://ftp.mfi. 
com/pub/gamedev/src/. It indudesthe 
various techniques and utilities dis- 
cussed in the series, and a new game to 
demonstrate their use. 
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Speeding up a game that ignores 
the basic code vocabulary of game pro- 
gramming is a no-brainer. Ours is basi- 
cally a sprite- based game, and no soft- 
ware-sprite-based game should be with- 
out dirty rectangles. I'm guessing that 
anyone reading this magazine has heard 
of dirty rectangles, but here's a quicl< 
review: a dirty rectangle algorithm lets 
you take advantage of visual similarities 
between frames by updating only the 
areas of the screen that have changed. 

In one implementation of a dirty 
rectangle algorithm, an application stores 
an image of the game in an offscreen 
buffer. W hen an object in the game 
moves, it erases the object in its old posi- 
tion in the buffer and draws it again in 
the new position, recording the coordi- 
nates of the areas affected by the change. 
To update the view, the game only has to 
bit the areas that have changed to the 
screen. 

In my sample game, I redrew and 
copied the entire game to the screen 
every frame, even though only a small 
portion of the rendered game changes 
when the sprites move. Lool< at some 
numbers, and you'll see why dirty rec- 
tangles are great. In the entire 500-by- 
350-pixel window, there are 175,000 
pixels, but the only things that change 
position in an average frame are small 
sprites. The ball is 10-by-lO and moves 
diagonally one pixel in either direction, 
so it affects an 11- by- 11— or 121— 
pixel area. The player's piece is 50- by- 
10 and will move one pixel horizontally, 
so it affects an area that's 51 by 10, or 
510 pixels. 

In other words, the game updates 
100% of the frame even though only 
0.32% of the frame changes. W hat idiot 
would do that? We can cut away those 
749,369 extra pixels by shoveling only 
the dirty areas to the screen. 

In fact, every pixel in the ball is the 
same color, so there's no point in redraw- 
ing the whole thing. A II we have to do is 
erase the trailing edge and draw in the 
leading edge, so instead of affecting 121 
pixels, the moving ball actually changes 
only 38 pixels. T he same goes for the 
player's piece: instead of 510 pixels, it 
actually changes only 10 pixels in front of 



it and 10 pixels behind it, as shown in 
Figure 1. Only 0.03% of the image 
changes every frame. 

T here's a tenfold difference between 
0.03% and 0.32%, but I'm going to 
implement the 0.32% version anyway. 
T he truth is, it's not going to make much 
of a difference. Video bandwidth, not 



I) dirfij recfanyle 
olgorifhm lefs you 
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main memory bandwidth, is generally a 
larger bottleneck, and we're still going to 
swap in the complete 11-by-ll and 51- 
by-10 areas. If the sprites were larger, it 
would make sense to spend more effort 
optimizing the bits, but this will be plen- 
ty fast. Besides, my computer freaked out 
on me, and I had to kill off my compiler 
before I could implement the 0.03% algo- 
rithm. 

Timing Valves 

T he source code for the 0.32% dirty rec- 
tangle rendering algorithm appears in 
L isting 1. But wait! There's more! If you 



implement that algorithm and try to play 
the game, you'll find that the Ice Age 
has become the W arp Age. N ow we're 
in game programmer's heaven— that 
mythical land where our game does 
everything we want it to do, and it's 
actually too fast. 

That's wonderful. Slowing a game 
down is infinitely easier than speeding it 
up. W e just use the timing functions I 
introduced earlier to put two valves on 
the game that control the speed of the 
paddle and the speed of the ball. We'll 
need two new members of CPad- 
dleGameWindou, called NextBallTime and 
NextPaddleTime, which tell the game 
when next to animate the two pieces, 
and two others, called BaiiSpeed and Pad- 
dleSpeed, which tell the game how to 
compute the NextBallTime and the 
NextPaddleTime. 

During Idle, the game checks the 
current time. If it's later than NextBall- 
Time, it calculates the motion of the ball 
and advances NextBallTime to be the cur- 
rent time plus BallSpeed. If it's later than 
NextPaddleTime, it calculates the motion 
of the paddle and sets NextPaddleTime to 
be the current time plus PaddieSpeed. W e 
control the speed of the game by adjust- 
ing the two speed variables. The higher 
the speed value, the slower that piece of 
the game will move. 

L isting 1 shows the heart of the 
modified CPaddleGameWindou::Idle COde. 
To help experiment with it, I also imple- 
mented code in KeyDoun, SO you can con- 
trol the ball speed using the -i- and - keys. 
You'll find that code on the ftp site if 
you're interested. 

Full Throttle 

T he coolest thing about timing valves is 
that you can open them up as the game 
progresses, pushing the game faster and 
faster as the player completes more and 
more levels. To determine whether a 
player has completed a level, CPad- 
dleGameWindou keeps track of how many 
blocks remain using the BlockCount 
member, decremented by CPad- 

dleGameWindou: :HitBlock when a wall is 

destroyed. If BlockCount reaches zero, 

CPaddleGameWindou: :InitGame will reset 

for the new level. 



36 GAME DEVELOPER • FEBRUARY/MARCH 1996 



Listing 1. Mostly Optimized XSplat 



i/oid CPaddleGameWindow: ;Idle(void) 
{ 

// Don't do anything while backgrounded 
if (lIsActiveFlag) 
return; 

// Control the frame rate 

long unsigned CurrentTiiiie = GetHiUisecondTimeO; 
if (CurrentTime < NextBaUTime M 
CurrentTime < NextPaddleTime) 
return; 

// 

// Prepare the buffer 

COffscreenBuffer* pBuffer = GetOffscreenBufferO; 
if (IpBuffer) 
return; 

pBuffer->Lock(); 

if (CurrentTime >= NextBaUTime) 
{ 

NextBaUTime = CurrentTime + BaUSpeed; 

// Erase the ball 
int BaUDirtyLeft = BaUX; 
int BaUDirtyRight = BallX + kBaUSize; 
int BaUDirtyTop = BaUY; 
int BaUDirtyBottom = BaUY + kBaUSize; 
FiURectangle(pBuf f er , 

BaUX, BaUY, kBaUSize, kBaUSize, 

kColorGameBackground) ; 

// 

// Hove the baU and calculate a bounce off any waUs 

// ♦***» CODE OMCTTED: SAME AS LAST MONTH ***** 
// ***** AVAILABLE ON THE FTP SUE ***** 

// Enlarge the baU's dirty rect 
if (BaUDirtyLeft > BaUX) BaUDirtyLeft = BaUX; 
if (BaUDirtyRight < BaUX + kBaUSize) 
BaUDirtyRight = BaUX + kBaUSize; 

if (BaUDirtyTop > BaUY) BaUDirtyTop = BaUY; 
if (BaUDirtyBottom < BaUY + kBaUSize) 
BaUDirtyBottom = BaUY + kBaUSize; 

// Draw the baU in its new position 
FiURectangle(pBuffer, 

BaUX, BaUY, kBaUSize, kBaUSize, 
kColorBaU) ; 

pBuffer->SwapRect(BaUDirt>Left, BaUDirtyTop, 
BaUDirtyRight, BaUDirtyBottom); 



// Perform any velocity changes due to bounces 

if (BounceX) BaUXSpeed = -BaUXSpeed; 
if (BounceY) BaUYSpeed = -BaUYSpeed; 

} 

// 

// FoUou the baU with the paddle center when in demo mode, 
// aUow the user to control the paddle in play mode 

if (CurrentTime >= NextPaddleTime) 
{ 

// Erase the paddle 
int PaddleDirtyLeft = PaddleX - kPaddle«idth/2; 
int PaddleDirtyRight = PaddleX + kPaddleWidth/2; 
FiURectangle(pBuf f er , 

PaddleX - kPaddle«idth/2, kPlayAreaBottom - kPaddleHeight, 

kPaddleUidth, kPaddleHeight, 

kColorGameBackground) ; 

NextPaddleTime = CurrentTime + PaddleSpeed; 

if (IsDemoHode) 
{ 

if (PaddleX < BaUX + kBaUSize/2) ++PaddleX; 
else if (PaddleX > BaUX + kBaUSize/2) -PaddleX; 

} 

else 
{ 

PaddleX += PaddleXSpeed; 

} 

// Bake sure the paddle doesn't mo»e out of the play area! 
if (PaddleX < kPlayAreaLeft + kPaddleUidth/2) 

PaddleX = kPlayAreaLeft + kPaddle«idth/2; 
else if (PaddleX > kPlayAreaRight - kPaddleUidth/2) 

PaddleX = kPlayAreaRight - kPaddle«idth/2; 

// Enlarge the paddle's dirty rect 

if (PaddleX - kPaddleUidth/2 < PaddleDirtyLeft) 

PaddleDirtyLeft = PaddleX - kPaddle«idth/2; 
if (PaddleX + kPaddleHeight/2 > PaddleDirtyRight) 

PaddleDirtyRight = PaddleX + kPaddleUidth/2; 

// Draw the paddle in its new position 
FiURectangle(pBuffer, 

PaddleX - kPaddle«idth/2, kPlayAreaBottom - kPaddleHeight, 

kPaddleUidth, kPaddleHeight, 

kColorPaddle); 

pBuffer->SwapRect(PaddleDirtyLeft, 
kPlayAreaBottom - kPaddleHeight, 
PaddleDirtyRight, kPlayAreaBottom) ; 

} 

pBuffer->Unlock(); 



Every five complete levels, we'll 
Increment the number of hits required 
to destroy each block, and for every 
level within those five, we'll Increase 
the ball speed by seven frames per sec- 
ond. If we Include a CurrentLevei mem- 
ber variable, the number of hits 



required to destroy a single block will 
be CurrentLevel/5 -I- 1, and BaUSpeed 
will be 1000 / (30 7 X (CurrentLevei % 
5)). Adding a few entries to the kColor- 
Block block array supplies colors for 
blocks requiring more than one hit to 
destroy. 



Listing 2 shows the new version of 
CPaddleGameWindou: :InitGaine that Imple- 
ments this behavior for us. nly one 
problem (for now): If you're playing the 
game on a system with a low-resolution 
timer, the timing valves don't work as 
smoothly as they should. For Instance, If 
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Listing 2. XSplat Level Initialization 



void CPaddleGameWindou: :InitGaiiie(»oid) 
{ 

// Start the paddle in the middle of the play area, not moving 
PaddleX = (kPlajAreaRight - kPlayAreaLeft)/2 + kPlayAreaLeft; 
PaddleXSpeed = 0; 

// Start the ball just above the paddle 
BallX = (kPlayAreaRight - kPlayAreaLeft)/2 + 

kPlajAreaLeft - kBallSize/2; 
BallV = kPlayAreaBottom - kBallSize - kPaddleHeight; 
// Move the ball towards the upper-left 
// TODO: Randomize initial ball velocity 
BallXSpeed = -1; 
BallVSpeed = -1; 

// Start Slowly - ball at 30 frames per second, increasing 7 fps every level 

BallSpeed = 1000 / (30 + 7 * (CurrentLevel 7, 5)); 

NextBallTime = GetHillisecondTimeO + BallSpeed; 

// Initialize the game field 

BlockCount = kUallUidthBlocks * kUallHeightBlocks ; 

int HitCount = CurrentLevel / 5 + 1; 

int Count; 

for (Count = 0; Count < BrickCount; ++Count) 

GameField [Count] = HitCount; 
// Draw the complete initial game state 
COffscreenBuffer *pBuffer = GetOffscreenBufferO; 
if (pBuffer) 
{ 

pBuffer->Lock(); 
DrawCompleteGameStateO ; 
pBuffer->Unlock(); 

} 

} 



you're playing on a M acintosh, GetHil- 
lisecondTime returns numbers in incre- 
ments of 17. The six-millisecond 
changes in ball speed won't be noticeable 
for three levels, when they finally exceed 
the resolution of the timer. At that 
point, you'll see one big jump in the 
speed of the ball. Timer resolution can 
be a huge hassle for programs like this, 
but it's a topic for another day. 

Speeding it up and adding increasing 
levels of difficulty pushes our paddle game 
play forward a long way. Players can still 
drop the ball with no penalty, which 
means they don't actually have to do any- 
thing, but we can fix that later. 

A Frayed Knot 

As for the three strings and the bigoted 
bartender, I can't even remember the 
whole jol<e, I can only remember how 
bad it is. ■ 

You can reach Jon Blossom via e-mail 
at blossom@slip.net or through Game 
D eveloper magazine. 
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elcome back! L ast time, if 
you recall, we discussed the 
input queue concept, the 
priority queue implementa- 
tion of the input queue man- 
ager, and how to capture and 
enqueue keyboard events. I n 
this concluding article, we're 
going to look at the other types of events 
the input queue manager can handle: 
those events generated by the mouse and 
timer as well as events defined and posted 
by the user. A s an added bonus, we're also 
going to talk about drawing the mouse 
cursor ourselves, in any video mode, so we 
don't have to worry about whether or not 
the mouse device driver supports that 
mode. 

Finally, at the end of the article, I 'II 
introduce a simple example game that's 
both gratuitously violent and a fine 
demonstration of the input queue manag- 
er's capabilities. 



Timer Events 

The input queue manager abstracts the 
interface to the system timer through 
countdown alarms. W hen an alarm is ini- 
tialized, it's given a starting count. W ith 
each clock tick, the alarm's count is decre- 
mented. W hen the alarm's count reaches 
zero, a timer.alarm event posts to the 
input queue, shown in F igure 1. 

A larms come in two flavors: one- shot 
and continuous. A one-shot alarm is dis- 
abled when its starting count reaches zero. 
A continuous alarm reenables itself with 
the same starting count as soon as it posts 
a timer.alarm event. T he input queue man- 
ager provides up to 16 alarms, numbered 
through 15, which are enabled using the 
INPQ_set_alarin() function. This routine 
accepts an alarm number and the starting 
count. It also takes a Boolean value indi- 
cating whether or not one- shot operation 
is desired. 

Before the alarm abstraction is feasi- 
ble, we need to provide a timer with a res- 
olution that is fine enough to be useful. 
Let's face it, the PC's standard resolution 
of 54.9 msjust doesn't cut it. To much can 
happen in 54.9 ms, especially with today's 
computers. Even the resolution that I set- 
tled on, 1 ms, is rather coarse; but if it 
were any faster, we'd spend altogether too 
much time in the timer interrupt handler 
to get any other work done. 

Without going into too much gory 
detail, the programmable interval timer 
(PIT) chip has three timer channels, each 
dedicated to a specific task. Channel 
handles the system clock, channel 1 takes 
care of D M A memory refresh, and chan- 
nel 2 controls the PC speaker. 

Of the three channels, we are going 
to choose to share the channel controlling 
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the system timer: channel 0. W e certainly 
wouldn't want to take over the channel 
controlling memory refresh (for obvious 
reasons), while the output line of the other 
channel is connected directly to the PC 
speaker and can't be made to generate an 
interrupt. 

Listing 1 contains the input queue 
manager timer control routines. W hen the 
machine starts up, PIT channel is pro- 
grammed by the PC bios to interrupt the 
machine 18.2 times a second (every 54.9 
ms). W hen the input queue manager timer 
is initialized, it first reprograms this chan- 
nel to a 1 ms resolution, which causes 
interrupts to occur 1,000 times a second. It 
then replaces the timer interrupt handler 
with our own specially constructed inter- 
rupt handler. ur handler counts the 
number of clock ticks that have elapsed 
and calls the BIOS timer interrupt handler 
every 54.9 ms (approximately). In addi- 
tion, our handler counts down each of the 
16 alarms and, if appropriate, generates 
timer events for alarms with expired 
counts. Alarms in continuous mode are 
reinitialized after their timer events have 
been enqueued. 

Mouse Events 

Until now, whenever we've wanted to 
gather events from a PC input device, the 
input queue manager has had to usurp 
control of that device at the interrupt han- 
dler level. W hile this approach certainly 
works, it is not a method I recommend to 
novices. Even veteran PC programmers 
can run up against unanticipated problems 
leading to frustrating hours of debugging. 

Luckily for us, we don't need to use 
this method to take control of the mouse 
W hen mouse support was added to PCs, 



someone took the time to design a well- 
thought-out and completeAPI to it. The 
mouse A PI is available after the mouse 
device driver has been loaded (this driver is 
usually supplied with the mouse hard- 
ware). nee loaded, the mouse driver API 
is available via interrupt 33h and provides 
an interface similar to M S-DOS's inter- 
rupt 2lh services. 

The mouse API provides a number 
of features we'll make use of: mouse 
detection and initialization, movement 
range and sensitivity adjustment, and, 
most importantly, the ability to specify a 
mouse event handler. 

Mouse Initialization 

Our initialization routine will configure 
the mouse to take full advantage of the 
desired graphics mode and install our 
mouse event handler. Subsequently, any 
mouse events that we've requested notifi- 
cation on (mouse movement, button 
presses, and so on) will cause our mouse 
event handler to be called. From there, we 
can figure out the type of the mouse event 
and whether or not an EVENT object should 
be created for it and posted to the input 
queue. 

Listing 2 contains excerpts from the 
input queue manager's mouse event code. 
Initialize.mouseO is called when the 
client specifies that mouse input is desired. 
Because the mouse handler supports any 
graphics mode for which a drau.mouseO 
routine has been implemented, the initial- 
ization routine accepts parameters specify- 
ing the current video mode. 

Since the first pixel of all video 
modes is assumed to be at C artesian coor- 
dinates (0,0), the initialization routine only 
requires that the user supply the maximum 
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Listing 1. limer.C 



#include "inpqpri».h" 
#pragma inline; 



** release.timer 
*/ 



/* 

** timer.events 
*/ 

static void interrupt timer.events (void); 
I* Local Data */ 

static »oid {interrupt *BIOS_tiiner_handler) (void) = NULL; 
static u32 clock.ticks; 
static ul6 counter; 



void release.timer (void) 
{ 

if (BlOS.timer.handler) 
{ 

outp (Pn_CQMHAND, Pn.SETFREQ); 
outp (Pn.CHO, 0); 
outp (Pn.CHO, 0); 

setvect (TIHERJNT, BIQS_tiiner_handler); 
BlOS.tinier.handler = NULL; 

} 

} 



/* Interface Global Routines */ 
/* 

** INPQ.set.alarm 
*/ 

void INPQ.set_alariii (sl6 alarmord, ul6 milliseconds, BOOLEAN one.sliot) 
{ 

if (alarmord < 1 1 alarmord > L*ST_ALARB) 
return; 

if (milliseconds <= 0) 
{ 

alarminit[alarmord] = -1; 
alarm[alarmord] = -1; 

} 

else 
{ 

if (!one_shot) 

alarminit[alarmord] = milliseconds; 
alarm[alarmord] = milliseconds; 

} 

} 

/* Library Global Routines */ 
/* 

** initialize.timer 

•/ 

BOOLEAN initialize.timer (void) 
{ 

if (!BIOS_timer_handler) 
{ 

clock.ticks = 0; 

counter = PCT.FREQ / MILLISECOND; 

outp (Pn.COMBAND, Pn.SETFREQ); 

outp (Pir.CHO, counter ii OxFF); 

outp (Pn.CHO, (counter 8i OxFFOO) » 8); 

BlOS.timer.handler = getvect (TIHER.INT); 

setvect (TIHER.INT, timer.events); 

return True; 

} 

return False; 

} 
/* 



/* 

** timer.events 
*/ 

static void interrupt timer.events (void) 
{ 

ul6 i; 
EVENT *e; 

// adjust the count of the clock ticks 
clock.ticks = clock.ticks + counter; 

// time to call the BIDS timer to update the time of day? 

if (clock.ticks >= BIQS.COUNT) 

{ 

// adjust clock tick count and call BIOS timer interrupt han- 
dler 

// (don't need to acknowledge interrupt since BIOS handler 

will.) 

clock.ticks -= BIOS.COUNT; 
asm { 

pushf 

call dword ptr BlOS.timer.handler 

} 

} 

else 
{ 

// acknowledge interrupt 

outp (PIC.REGISTER, NONSPECIFIC.EOI) ; 

} 

// process count-down timers, post events if appropriate 
for (i=0; i<=LAST.ALARH; i++) 

if (alarm[i] > 0) 

{ 

— alarm [i] ; 
if (!alarm[i]) 
{ 

// queue timeout event 
e = allocate.event (); 
e->type = timer.alarm; 
e->data. timer. alarm = i; 
alarm [i] = alarminit[i] ; 

} 

} 

} 



(x,y) coordinates of the mode. Pay close 
attention to this detail; the maximum (x,y) 
coordinate of a video mode is not the reso- 
lution of the mode. For example, M ode 
13h has a resolution of 320 by 200, but its 



maximum coordinate is (319,199). We 
also need to know how many bytes make 
up a single scanline in the current mode 
because drawing the cursor is an inherently 
rectangular operation. 



Finally, to support double buffering 
(M ode 13h) and page flipping (M ode X), 
we need a pointer to a routine that 
returns the current frame buffer address. 
This address is returned as a far pointer 



42 GAME DEVELOPER • FEBRUARY/MARCH 1996 



Table 1. Register State when Mouse Event Handler is Called 



Mouse Event Flags 


Result 


BitO 


Mouse movement 


Bitl 


Left button down 


Bit 2 


Left button up 


Bits 


Right button down 


Bit4 


Right button up 


Bits 


Center button down 


Bite 


Center button up 


Bits 7 to 15 


Reserved (0) 


Button State: 


Result 


BitO 


Left button is down 


Bitl 


Right button is down 


Bit 2 


Center button is down 


Bits 3 to 15 


Reserved (0) 



because it is not necessarily going to be 
pointing to video memory. 

T he first thing the initialization rou- 
tine does is grab a pointer to thelnDDS flag. 
This flag is nonzero when a D S int 21h 
function is currently processing. If this flag 
is set when we enter our mouse event han- 
dler, we immediately exit back to the 
mouse driver (though the situation proba- 
bly never occurs, it's best to check for it). 

N ext, we ensure that the video sys- 
tem is in graphics mode T he input queue 
manager doesn't support text mode 
mouse cursors. After this, we actually 
move on to initializing the mouse Because 
the input queue manager overrides a num- 
ber of functions provided by the mouse 
driver API, the names of all the functions 
that actually talk to the mouse device dri- 
ver are prefixed with an int33h.. The 
int33h_init_inouse() routine requests the 
mouse driver API determine if a mouse is 
present and, if so, reset it to default opera- 
tional values. If the mouse was properly 
initialized, this routine returns a nonzero 
value. 

If the mouse was successfully initial- 
ized, the mouse cursor interface is initial- 
ized with a call to MClTF.initO. H ere, all 
the video mode parameters required by 
initialize.mouseO are passed on to be 
stored for later use. W e will discuss the 
mouse cursor interface and its associated 
routines later. 

By default, the mouse device driver 
assumes a graphics resolution of 640 by 
200. Because this is almost certainly not 
the desired resolution, we call 
int33h_set_inouse_limits() to adjust the 
limits and sensitivity of the mouse. This 
routine makes three calls into the mouse 
driver API to set the horizontal limits 
(0..inax_x), the vertical limits (0..inax_y), 

and the sensitivity of the mouse. 

T he hardware mouse driver also ini- 
tializes the mouse position at the center 
of the screen. This position is no longer 
going to be valid. Therefore, the initial- 
ization routine calculates a new center 
location from the maximum horizontal 
and vertical positions and uses 
int33h_set_inouse_position() to move the 
cursor there 

The default configuration of the 
mouse driver A P I does not provide a 



cx Horizontal (x) pointer coordinate 

dx Vertical (y) pointer coordinate 

si Last raw vertical mickey count 

di Last raw horizontal mickey count 

ds IV| ouse driver data segment 



mouse event handler. T he client is expect- 
ed to poll for changes in the mouse's state 
Because we want to be notified automati- 
cally when the mouse state changes, we are 
going to introduce a mouse event handler 
into the equation. 

Int33h_set_event_handler() registers 
a mouse event handler with the mouse 
device driver. W hen a mouse event han- 
dler is registered with the mouse device 
driver, a mask of the events that the han- 
dler is interested in is supplied. Subse- 
quently, the mouse device driver will only 
call the mouse event handler when those 
specific events occur. The bit mask the 
input queue manager passes to the mouse 
device driver indicates that it will be han- 
dling all mouse events. 

Finally, we register the default cursor 
shape with the mouse cursor interface via 
the MClTF.shapeO routine The last thing 
the initialization does before returning a 
True indication is to set the mouse.visible 
variable to -1 (for reasons I 'II explain). 

Mouse Visibility 

The mouse cursor is only made visible 
when the mouse.uisible variable transi- 
tions from -1 to on a call to 
lNPQ_shou_inouse(). Subsequent calls to 
lNPQ_show_mouse() have no effect on this 



value. Calls to INPQ_hide_mouse(), on the 
other hand, always decrement this vari- 
able. If the value transitions from to - 
1, the visible mouse cursor is hidden. 
Thus, every call to INPQ_hide_mouse() 
must be matched with a call to 
iNPQ_show_mouse() before the mouse will 
again become visible, while excess calls 
to lNPq_shou_mouse() are ignored. These 
semantics match those defined by the 
mouse driver A PI . 

Calls to INPq_shou_mouse() and 
iNPQ_hide_mouse() don't just affect the visi- 
bility of the mouse cursor, they also affect 
whether mouse events are gathered. T he 
mouse event handler checks the mouse. vis- 
ible variable before the mouse cursor 
update and if it's nonzero, exits the mouse 
event handler altogether. 

I n some situations, this is the desired 
effect, but if we're double buffering or page 
flipping, we want mouse events enabled 
even when we've hidden the mouse cursor 
so that we can draw the next frame. To 
support this, the input queue manager 
API includes two functions to show and 
hide the mouse cursor without affecting 
event gathering: iNPQ.obscure.mouseO and 
INPQ_unobscure_inouse(). 

T he obscure and unobscure function- 
ality is implemented at the lowest level, 
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Listing 2. Excerpts from jvlouse.C (Continued on p. 45) 



tindude "inpqpri».h" 
#include "mcitf.h" 

/* 

** initialize mouse 
*/ 



// only hide the mouse cursor if the mouse_visible variable 

// transitions from to -1. 

// 

if (— mouse_»isible == -1) 
BCCTF_draw (-1, -1); 



BOOLEHN initialize_mouse (sl6 max.x, sl6 max.y, 
ul6 bytes_per_scanline, 
u32 (far *acti»e_page) (void)) 

{ 

union REGS regs; 
struct SREGS sregs; 

segread (!isregs); 

regs. h. ah = GET_INDOS_FLAG; 

intdosx (&regs, iiregs, Sisregs); 

InDOS = HK_FP (sregs.es, regs.x.bx); 

// make sure that we are in graphics mode (this handler 
// is for use with the GFX library and doesn't support 
// text cursor updates). 

regs. h. ah = GET.VIDEO.HODE; 
int86 (VIDEO.INT, Siregs, &regs); 

if (regs.h.al <= 4 1 1 regs.h.al == 7) // modes 0-4 & 7 are text 
modes 

return False; 

if (!int33h_init_iiiouse ()) 
return False; 



/* 

♦* INPQ_mouse_visible 
*/ 

BOOLEAN INPQ_mouse_ visible (void) 
{ 

return mouse. visible == 0; 

} 
/* 

** INPQ.obscure.mouse 
*/ 

void INPQ.obscure.mouse (void) 
{ 

extern BOOLESN BClTF_obscure; 

if (!lNPQ_mouse_visible ()) 
return; 

if (!HCnF_obscure) 
{ 

BCITF_draw (-1, -1); 
BCITF_obscure = True; 

} 



// call mode specific mouse initialization 

MCITF.init (max_x, max_y, bytes_per_scanline, active.page) ; 

int33h_set_iiiouse_limits (max_x, max.y, 8, 8); 



/* 

♦* INPQ.unobscure.mouse 
*/ 



current_x = (max_x + 1) / 2; 

current_y = (max_y + 1) / 2; 

int33h_set_iiiouse_position (current_x, current_y); 

int33h_set_event_handler (HLL_HOUSE_EVENTS, mouse.events) ; 

MCITF.shape ( 

default_cursor, def ault_width , default.height, 
default_hotspot_x, default_hotspot_y, 1, 0); 

mouse.visible = -1; 
return True; 



/* 

** INPQ.show.mouse 
*/ 

void INPQ.show.mouse (void) 
{ 

// Only show the mouse cursor if the mouse.visible variable 
// transitions from negative to zero, 
if (mouse.visible == 1 1 ++mouse_visible != 0) 
return; 

MCITF.draw (current.x, current.y); 

} 

/♦ 

*» INPQ_hide_mouse 
*/ 

void INPQ.hide.mouse (void) 



void INPQ.unobscure.mouse (void) 
{ 

extern BOOLESN BCITF.obscure; 

if (!lNPQ_mouse_visible ()) 
return; 

if (nCITF.obscure) 
{ 

BCITF_obscure = False; 
BCITF_draw (current_x, current.y); 

} 

} 
/* 

** mouse.events 
*/ 

static void far mouse.events (void) 
{ 

// on entrance, registers are set up as follows: 



// 






// 


ax ■ 


= mouse event flags 


// 


= 


mouse movement 


// 


1 = 


left button down 


// 


2 = 


left button up 


// 


3 = 


right button down 


// 


4 = 


right button up 


// 


5 = 


center button down 


// 


6 = 


center button up 
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Listing 2. Excerpt from jvlouse.C (Continued on p. 46) 



// 7-15 reserved (0) 




mov region, ax 


// bx = button state 






// = left button is down 




mov ax, 


// 1 = right button is down 




mov dx, event.flags 


112 = center button is down 




test dx, EF.MOUSEJOVEMENT 


// 3-15 reserved (0) 




Jz but^tion down 


// cx = horizontal (X) pointer coordinate 




or ax, mouse move 


// dx = vertical (V) pointer coordinate 




} 


// si = last raw vertical mickey count 






// di = last raw horizontal mickey count 




button.down : 


// ds = mouse driver data segment 




asm { 






test dx, EF_nOUSE_BUTTON_DD«N 


sl6 X, y; 




jz button_up 


sl6 region; 




or ax, mouse.down 


ul6 event.flags, event.mask, button.state; 




} 


asm { 




button_up: 


push ax 




asm { 


push bx 




test dx, EF_HOUSE.BUTTON.UP 


push cx 




jz verify.event 


push dx 




or ax, mouse.up 


push si 




} 


push di 






push ds 




verify_event: 


push es 




asm { 






test ax, events.enabled 


mo» event.flags, ax 




jnz queue.event 


mov button.state, bx 




jmp clear.mouse.event 


mov X, cx 




} 


mov y, dx 










queue.event: 


mov ax, DGROUP 




asm { 


mov ds, ax 




mov event.mask, ax 


} 










call far ptr allocate.event // returns far ptr to 


if (InHouseEvent) goto clear_mouse_event; 




event in dx:ax 


InNouseEvent = True; 




cmp dx, // null pointer returned? 






je queue.overflow // drop event 


asm { 






mov cx, X 




mov bx, ax // move dx:ax => es:bx 


mov dx, y 




mov es, dx 


mov current_x, cx 






mov current_y, dx 




mov ax, event.mask 






mov es : [bx] . type, ax 


// see if the cursor is visible to the user (mouse.visible == 










mov dx, event.flags 


test mouse.visible, OxFFFF 




mov cx, button. state 


jz draw.cursor 






jmp clear.mouse.event 




mov ah, 


} 




test dx, EF.LEFT.BUTTON 






jnz set.left 


draw.cursor: 




test cx, BS.LEFT.DOUN 


HCnF_draw (x, y); 




jz right button 

} 


if (*InDOS) asm jmp clear.mouse.event 










set.left: 


asm { 




3sin { 


// register event for this interrupt (if applicable) 




or ah, LEFT BUTTON 


push y 




} 


push X 






("all far" ntr in roirinn 




1 -i-gll L_UU LLUII ■ 


add sp, 4 




asm { 


cmp ax, -1 




test dx, EF.RIGHT.BUTTON 


jne check.events 




jnz set.right 


jmp clear.mouse.event 




test cx, BS.RIGHT.DOUN 


} 




jz center button 

} 


check.events: 






asm { 




set.right: 
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within the routine that draws the mouse 
cursor to the frame buffer. The show and 
hide functionality, on the other hand, is 
implemented at the topmost level, within 
the input queue manager itself. 

The obscure and unobscure model 
does not follow the mouse driver API 
nesting rules. Obscurity is maintained as 
a Boolean value by the mouse cursor 
interface rather than as a counter. 

The Mouse Event Handler 

N ow, let's examine the actual mouse 
event handler. This handler is called by 
the mouse driver any time a mouse event 
occurs. Table 1 defines the state of the 
CPU registers when this routine is called. 
Because the interface is register based, I 
decided to code the mouse driver in in- 
line assembly language. 

The first thing our mouse event 
handler does is save the input data to the 
stack. T he x86 processors have never had 
enough registers, so it just doesn't pay to 
keep values in them over the course of a 
routine as large as this one. 

ne thing to pay close attention to 
here is that the mouse device driver calls 
our mouse event handler with its own 
data segment in DS. To access our own 
program specific data, we must reset the 
data segment register. This is easily 
accomplished by moving DGROUP, the 
linker symbol for our data segment, into 

DS. 

Next, we do a little cursor house- 
keeping. T he current x and y coordinates 
of the mouse cursor are copied to a pair 
of global variables. These variables 
maintain the input queue manager's con- 
cept of the current mouse cursor loca- 
tion. W e also draw the mouse cursor at 
this point if it is currently visible (or 
erase it if it's still visible when it 
shouldn't be). 

N ow we're ready to determine if we 
need to translate the mouse event into an 
input queue event. The first check we 
make is to determine if we are within a 
region the user registered to receive 
mouse events from. 

If the current mouse event has 
occurred within a defined mouse region, 
the region number is saved away for pos- 
sible later use. Next, we build the event 



Listing 2. Continued from p. 45 



asm { 

or ah, RIGHT_BUTTON 

} 

center_button: 
asm { 

test dx, EF.CENTER.BUTTON 
jnz set.center 
test cx, BS.CENTER.DOWN 
jz set_attributes 

} 

set_center: 
asm { 

or ah, CENTER.BUnON 

} 

set.attributes: 
asm { 

mo» al, byte ptr region 
mo» es: [bx] .attr, ax 

mov ax, X 

mov es: [bx] .data, ax 
mov ax, y 

mo» es: [bx] .data+2, ax 
jmp clear.mouse.ei/ent 

} 

queue.overflow: 
asm { 

inc lost.input 

} 

clear_mouse_e»ent: 
InMouseEvent = False; 

asm { 

pop es 
pop ds 
pop di 
pop si 
pop dx 
pop cx 
pop bx 
pop ax 

} 

InMouseEvent = False; 

} 



type word and check to see if the client 
requested notification for these specific 
events. If so, an event will be posted to 
the input queue. Figure 2 depicts the 
structure of a mouse event. 

The event is constructed and 
enqueued by calling allocate.eventO (I 
described this routine in my previous arti- 
cle). The event structure returned by this 
routine is then filled in with the event 
type, current state of all the buttons, the 
region within which the event occurred. 



and the current (x,y) coordinates of the 
mouse cursor. 

Mouse Regions 

I 'd like to spend just a little time talking 
about mouse regions and their intended 
use The first thing I 'd like to point out is 
that mouse regions, unfortunately, are 
brain- dead. 

M ouse regions are rectangular areas 
of screen space. W hen the mouse cursor 
is within one of these regions, all mouse 
events that have been requested by the 
client are returned as input queue events. 
Likewise, if mouse events occur outside 
any mouse region, regardless of whether 
the client enabled the mouse event, no 
input queue events are posted. 

n the plus side, mouse regions are 
great for reducing the number of mouse 
events enqueued. M ost of the time, there 
is no reason to handle movement events, it 
just wastes processor cycles. M ouse 
regions, by their very nature, eliminate the 
majority of excess movement events. 
M ouse regions work great for dialog boxes 
and static introduction screens where there 
are a number of boxes or buttons that can 
be poked and prodded with the mouse 
cursor. 

W here mouse regions fail, though, 
is with any sort of animation. This failure 
is due mainly to the fact that mouse 
regions cannot overlap. The current 
implementation has no concept of over- 
lapping regions and won't allow a region 
to be defined if it overlaps an existing 
region. If you want to animate a sprite 
over some region of the screen, do not 
expect to be able to define an object that 
the sprite can interact with anywhere 
within the same region. It's pretty obvi- 
ous that mouse regions aren't particularly 
useful. 

W ith these caveats in mind, we'll 
move on to the actual implementation of 
mouse regions. 

M ouse regions are maintained as a 
stack of region lists. When iNPQ.push 
_(nouse_regions() is called, a new entry is 
placed on top of the region stack. T he new 
entry contains an empty region list. 
INPQ.define.regionO is then called with 
the upper-left and lower-right screen coor- 
dinates of the region being defined. If the 
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region doesn't overlap with a previously 
defined region, it is added to the current 
region list. W hen you're done with the 
current list of regions, INPQ.pop_regions() 
removes and discards the list of regions on 
top of the stack. By default, the input 
queue manager defines one region list con- 
taining a single region encompassing the 
entire visible screen. This region is never 

popped byINPQ_pop_regions(). 

The Mouse 
Cursor Interface 

The mouse cursor interface defines a 
mode-independent API that allows a 
program to control how the mouse cursor 
is displayed. The mouse cursor interface 
comprises three functions: HCllF.initO, 
MCITF.shapeO, and MCITF_drau(). I've pro- 
vided implementations of these three 
functions for M ode 13h and M ode X . 

All the mouse cursor interface rou- 
tines are written in assembly language. 
There really is no good reason that the 
first two routines weren't written in C. 
They would certainly be more readable if 
they had been. But when I started the 
implementation of the input queue man- 
ager, quite a bit was written in assembly 
language, and I just haven't seen any 
pressing reasons to convert these routines. 

L isting 3 contains the code to ini- 
tialize the mouse cursor interface as well 
as the code to change the mouse cursor's 
shape and hotspot. MClTF.initO initializes 
the mouse cursor interface by storing 
away the current video mode information. 

MCITF.shapeO updates the bitmap (or 
masl<s) that control how the mouse cursor 
is displayed. This routine accepts mouse 
cursor shapes specified in one of two for- 
mats: one bit per pixel or eight bits per 
pixel. 

In one- bit- per- pixel mode, the 
bitmap pointer points to the start of two 
concatenated masks. The first mask is 
ANDed with the screen contents to create a 
"hole" in the current image. The mouse 
cursor is then displayed within the hole 
by XORing in the second mask. To mini- 
mize the amount of calculation required 
when the mouse cursor is actually being 
displayed, the and and XOR masks are 
expanded into eight- bits- per- pixel repre- 
sentations as they are copied to the mouse 



Figure 2. Mouse Event Structure 




cursor save buffers within the mouse cur- 
sor interface. C urrently, the mouse cursor 
interface doesn't know how to deal with 
16- or 24- bit color. 

In eight-bits-per-pixel mode, 
which I've dubbed direct mode in the 
source code, the bitmap pointer points 
to a block of memory that can be trans- 
ferred verbatim to video memory. This 
block of data is copied without transla- 
tion to the mouse cursor save buffer. 

ne- bit- per- pixel mode is the clas- 
sic method of drawing a mouse cursor. If 
you use the change cursor shape routines 
available via the mouse driver API, this 
is the format that is expected. E ight- 
bits- per- pixel mode was added because 
it has become quite common in point- 
and- click style games to change the 
mouse cursor to some arbitrary bitmap 
that isn't representable using the and/xor 
method of drawing the cursor. 

Drawing the Mouse Cursor 

T he MCUF.drauO routine is called to erase 
the previous mouse cursor from the cur- 
rent frame and (possibly) redraw it at 
another location. If you examine the code 
in Listing 3, you'll notice that while the 
listing is long, it's actually divided into 
three distinct parts: 

• Common initialization code 
■ M ode-specific code 

• Common exit code. 

T his file must be compiled separate- 
ly for M ode 13h and M ode X. Ideally, 



you'll choose one mode or the other with- 
out needing to switch between them in 
the middle of your program. The make- 
files, provided in the archive, build both 
types of libraries for you. 

Let's start at the top. After saving 
away registers and making sure we know 
what our data segment is pointing to, we 
check to see if we're being called recursive- 
ly or if the mouse cursor is currently 
obscured. Both conditions cause immedi- 
ate exit. 

N ext, we determine where our frame 
buffer is by calling the user supplied 
actiue.pageO routine (passed as a parame- 
ter to MCITF.initO). T his routine returns a 
pointer to the current frame buffer. This 
can be in main memory or somewhere in 
video memory, it really doesn't matter to 
the MClTF.drauO routine. W hat is of con- 
cern to us is that, for every allocated page, 
we have a separate save space to store the 
previous background and cursor clipping 
information. 

I designed the interface with the 
expectation that, in M ode 13h, double- 
buffering would be available through the 
use of a single main memory buffer. In 
M ode X, I assumed double-buffering or 
triple-buffering would be available via 
page-flipping. Because up to three frames 
could be active simultaneously, I statically 
allocated space for three mouse save areas. 
T hese areas are initialized to - 1 at startup. 

The next section of code runs 
through these save areas to see if it can 
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Listing 3. Excerpts from |VICIINIT.ASIV| and |VICISHAPE.ASIV| (Continued on p. 49) 




** 




mov ax, seg and.mask 




** void HCrrF_init (sl6 max.x, sl6 max_y, 




mov es, ax 




** sl6 bytes_per_scanline. 




mov di, offset and.mask 




** u32 (far *active_page) (void)) 










** 




mov ax, cursor_width ; calculate number of bytes 






mov cx, cursor_height ; in the packed representation 


.WCITF_init proc far 




mul cx 


arg _max_x:word, _iiiax_y:uord, _bytes_per_scanline:word,\ 




mov mask_size, ax 


_acti«e.page:duord 












mov direct, 


push bp 








mov bp, sp 




Ids si, bitmap 


moK ax, .max.x 




cmp bits_per_pixel, 1 


mov max_x, ax 




jne @@eight_bits_per.pixel 


mov ax, .max_y 








mov max_y, ax 




9aone.bit_per_pixel: 


mov ax, _bytes_per_scanline 








mov bytes_per_scanline, ax 






es:di -> and.mask 


mov eax, _active_page 






es: di+CURSOR.SAVE.SIZE -> xor.mask 


mov acti»e_page, eax 






ds:si -> and bitmap 








ds: si+bx -> xor bitmap 


pop bp 








ret 




mov cx, ax 






shr cx, 3 


.NCITF.init endp 




mov bx, cx ; cx is count, bx is offset 






mov al, 80h 




** 




Mset.mask: 




** BOOLEAN nCITF.shape (u8 far *bitmap. 




test byte ptr [si] , al 




** ul6 width, ul6 height, 




jnz @@set_and_mask 




** ul6 hotspot.x, ul6 hotspot.y. 




mov byte ptr es: [di] , 




** ul6 bits_per_pixel, u8 transparent) 




jmp 9@do_xor.mask 




** 




99set.and_mask : 






mov byte ptr es:[di], OFFh 




.nCITF_shape proc far 




99do.xor 


_mask: 


arg bitiiiap:duord, uidthrword, heiglit:word, \ 




test byte ptr [si+bx], al 


hotspot_x:word, hotspot_y:word, bits_per_pixel:word,\ 




jnz @@set_xor_mask 


transparent:word 




mov byte ptr es: [di+CURSOR.S»VE.SIZE] , 


local mask.size:word, direct :word=AUTO.SIZE 




jmp 9@next_mask 






99set_xor.mask: 


push bp 




mov byte ptr es: [di+CURSOR.SAVE.SIZE] , OFh 


mov bp, sp 




Sflnext.mask: 


sub sp, AUTO.SHE 




inc di 






shr al, 1 


push di 




jnz @@set_mask 


push si 








push ax 




dec cx 


push bx 




jz 9@fini 


push cx 








push ds 




mov al, 80h 






inc si 


mov ax, width 




jmp Sfiset.mask 


cup ax, MU.CURSOR.UIDTH 








jg 9®error_exit 




S@eight_bits_per_pixel: 


mov cursor_width, ax 






In 8-bits/pixel mode, there is no and/xor masking going on. 






He just copy the bytes as-is to the and.mask location and put them 


mov ax, height 






directly to the display when we draw the cursor. 


cmp ax, n*X_CURSOR_HEIGHT 








jg 99error_exit 






es:di -> and.mask 


mov cursor.height, ax 






ds:si -> bitmap 


mov ax, hotspot_x 






,mp bits.per.pixel, 8 


mov bx, hotspot,y 




jne @@error_exit 


mov hot.x, ax 








mov hot.y, bx 




mov cx, mask_size 






rep movsb 


mov ax, transparent 








mov mtransparent, al 




mov direct, 1 






jmp @@fini 
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match the current frame address, referred 
to as the "current page," with a previously 
stored page value. If it encounters a -1 
page value before it encounters a match- 
ing page, it knows that the page has never 
been seen before and can be allocated to 
the current save slot. 

nee we know where the save loca- 
tion for the current frame is, we mirror its 
contents to a series of stack variables. 
W hy? Because we don't have enough reg- 
isters that can be used as base registers in 
16-bit mode (the same problem we 
encountered when we were talking about 
the mouse event handler). Instead, we get 
to waste lots of time copying data to the 
stack and later copying it back to its save 
slot when a mouse is drawn or erased. 
nee we've mirrored the data, it's time to 
move on to actually erasing the previous 
mouse cursor. 

For simplicity, the following discus- 
sion is going to concentrate on drawing 
the mouse cursor in M ode 13h. The 
structure of the code in the M ode X 
block is the same, it just has to do more 
work to draw to the video buffer. 

The first thing we check is whether 
or not there is an existing cursor that 



Listing 3. Continued, from p. 48 



9Serror_exit: 

mo» ax, 

jmp Mfinal_exit 

Mfini: 

mo» ax, 1 

9Sfinal_exit: 
pop ds 

mo» bx, direct 
ino» direct.draw, bx 

pop cx 
pop bx 
pop ax 
pop si 
pop di 

mov sp, bp 
pop bp 
ret 

_MCITF_shape endp 



needs to be erased. If the screen offset 
(stored in the cursor save area) is-1, there 
isn't a mouse cursor to erase. The screen 
offset will be -1 in only two cases: the 
first time MCITF.drauO is called and when 
the cursor wasn't drawn the last time the 
current page was updated. 

If there is a cursor on the current 
page, all the required information is read 
from the cursor save variables, and a loop 
is entered to copy the save data from the 
cursor save area to the current page, effec- 
tively erasing the cursor from the page 

T he drawing phase starts by writing a 
-1 to the screen offset and checking to see 
if we need to draw the cursor or not. I f the 
x-coordinate is less than zero, the cursor is 
hidden, and we return immediately. 

I f the cursor isn't hidden, we need to 
reset a number of upkeep variables to their 
default values. Mouse.x and mouse.y are the 
(x,y) offsets into the mouse cursor bitmap 
denoting the starting byte of the mouse 
cursor. These values may be modified by 
the clipping process. House_skip is the dif- 
ference between the width of the mouse 
cursor and the number of bytes per scan- 
line. If we've just drawn a row of the 
mouse cursor, we can add this value to the 
current x coordinate to get to the first byte 
of the next row. Finally, mouse.uidth and 
mouse.height are the clipped width and 
height of the mouse cursor, respectively. 

Before we can actually draw the 
mouse cursor into the frame buffer, we 
must clip it against the frame buffer's 
boundaries. All clipping takes place in 
relation to the mouse cursor's hotspot, 
which is not necessarily going to be at the 
upper left corner of the cursor rectangle. 
We must clip in relation to the cursor's 
hotspot because the coordinate of the 
hotspot is returned to the client when the 
current mouse position is requested. 

Clipping against the hotspot isn't as 
bad as it sounds because we are able to 
clip the X- and y-axes independently. To 
clip along the y-axis, we first subtract out 
our y-axis hotspot position. If the resulting 
y coordinate is greater than zero, then the 
mouse cursor lies completely within the 
display area vertically. 

If the adjusted y- coordinate is nega- 
tive, then we need to "shear off" the top 
of the mouse cursor. W e negate the y- 



coordinate to find out how many pixels 
we need to lose T his value is then added 
to the mouse_y variable and subtracted 
from the mouse.height. If the mouse.height 
goes to zero, the mouse cursor is totally 
obscured and need not be drawn. 

Next, we clip the y-coordinate 
against the bottom of the screen. W e do 
this by adding the height of the mouse 
cursor to the previously calculated hotspot 
coordinate and check to see if the result- 
ing coordinate exceeds our maximum y- 
coordinate. If so, we reduce the 
mouse.height by the required amount and 
again check to see if the height goes to 
zero, exiting if it does. 

Otherwise, we move on to clipping 
along the x-axis, which I won't go into 
because it is analogous to the discussion of 
y-axis clipping (replacing "top" references 
with "left" and "bottom" references with 
"right"). 

After we've performed clipping, we 
need to figure out where in the frame 
buffer we need to draw the cursor. The 
H13H.PIXEL.0FFSET macro figures this out in 
an efficient manner. T he offset is added to 
the current frame buffer address, and the 
result is placed in the screen offset save 
location. Next, the offset into the mouse 
cursor bitmap (or masks), specified by 
(mouse.x, mouse.y), is calculated using the 
HOUSE.OFFSET macro. W ith these two offsets 
calculated, the rest of the work is just set- 
ting up registers required for our draw 
loop. T he last check made before we actu- 
ally draw anything is whether or not we're 
in direct draw mode or not. 

Both draw loops are nearly identical; 
for each pixel, the current page value is 
grabbed and saved in the cursor save area. 
New cursor data is placed in the display 
buffer, either directly or via the and/xor 
mechanism. While in direct draw mode, 
there is an additional transparent pixel 
check. If the current pixel value is equal to 
the specified transparent pixel value, noth- 
ing is drawn, and the background will 
show through the mouse cursor. 

W hen the entire mouse cursor has 
been displayed, we jump down to the 
common exit code. T his code saves all the 
stack values back to the appropriate cur- 
sor save location, pops all the saved regis- 
ters from the stack, and returns. 
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R G n N I Z I n USER INPUT 




This is a screensliot taken from tlie ducl( liunt program, wliicli you can access on tlie Game 
Developerftp site. It illustrates the principles discussed in this series. 



This same code structure may be 
used to draw the mouse cursor in any 
mode. In addition to M ode 13h and 
M ode X, I've also implemented a mouse 
draw routine for 8-bit VE SA modes. 
U nfortunately, the code is much too inef- 
ficient (and therefore embarrassing) to 
release. 

User-Defined Events 

If you examine the e«ent_type structure, 
you'll notice that very few of the bits 
available are used for predefined events. 
I n fact, the entire range from 0x0040 to 
0x8000 is available for user-defined events. 

A user- defined event may be any- 
thing you feel needs to be managed along 
with other input. For example, you might 
want to add user-defined events for joy- 
stick or H M D input. 

To define an event, choose an ordi- 
nal from the unused range. I suggest 
starting with 0x8000 and working back- 
ward (if you're adding multiple events). 
This provides a vivid distinction between 
your events and predefined events when 
you're debugging your code. N ext, you 
need to define structures analogous to the 
.ATTR and _DSTA structures provided for 
keyboard, mouse, and timer events. That 
is, you need to define a 16- bit attribute 
structure and a 32- bit data structure that 
your event handler will fill in. 

That's it for data definitions. W ithin 
your initialization code, you'll need to call 



INPq.enable.userO, passing the EUENT.TYPE 

ordinal you've chosen and a pointer to an 
initialization routine. At a minimum, this 
routine needs to return a nonzero value to 
indicate that the initialization completed 
successfully and events of this type may 
be enabled. You may use this routine, of 
course, to load any interrupt handlers or 
do any other startup that your event 
requires. 

You may then enqueue events by 
calling iNPQ.enqueueO. You must have 
already constructed your data and attrib- 
utes structures when you make this call. 
This routine will allocate an available 
event, fill in each of the fields and post 
the event to the input queue. 

I've created a simple program that 
demonstrates user- defined events by cap- 
turing joystick state changes and translat- 
ing them so that they result in mouse-like 
behavior. This example program may be 
found in the test subdirectory of the 
source archive, in thefilesJOYSTICK.H 
andJOYSTICK.C. 

Duck Hunt 

The duck hunt example program 
(H UNT.H and H UNT.C in the test 
subdirectory of the source archive) is a 
fairly complete example of everything 
that we've discussed in the last two arti- 
cles (and some things we haven't). Basi- 
cally, this program flies ducks across the 
screen and lets you target them with the 



cursor. nee targeted, you may blow the 
ducks away with reckless abandon. 

You may use the mouse, the key- 
board, or the joystick to target and shoot 
the ducks. Frame- rate limiting and 
frames- per- second counting are provid- 
ed using two separate timer alarms. 

All in all, this program is a fairly 
good demonstration of the capabilities 
and ease of use of the input queue man- 
ager, even if the "game" isn't particularly 
challenging. 

Also, don't forget to take a look at 
G FX .C , a small graphics library for 
M ode 13h and M ode X that fully sup- 
ports double-buffering and page-flipping 
(albeit, written in C and fairly slow). It's 
not much, but it can provide the basis for 
your own efforts along these lines. 

Now You Can Manage 

That's about all I have to say for now 
about the input queue manager. I plan 
on converting this code for use in a 32- 
bit flat model environment in my copi- 
ous free time, but that's fodder for 
another article. I'd like to thank M ark 
Delmont for contributing the artwork 
for the D uck H unt example. W ithout 
his help, we'd all be shooting white rec- 
tangles on a blue background (and I'd 
have to figure out a new name for the 
program)! 

As always, the complete input queue 
manager source code may be obtained 
from the Game Developer ftp site 
(ftp://ftp.mfi.com in the gamedev/src/ 
directory) or on CompuServe (Game 
Developer Library of SDFORUM ). If 
you don't have access to either resource, 
but you do have an e-mail address, I 'd be 
happy to send you a uuencoded version of 
the archive. Just send mail to inpq- 
source@irvine.com with a subject line of 
"inpq source". ■ 



M ike M ichaels is a senior software 
engineer at a smaii Irvine, Caiif. -based 
company. Whiie he searches in vain for a 
computer game company that can matdi his 
aerospace salary, he develops his own ideas 
at homein his nonexistent sparetime Con- 
tact him via e-mail at mike@irvinecom or 
through Game Developer magazine 
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Object Cache 
Manage me n't 



Most video games are con- 
strained by memory limita- 
tions. I n a perfect world, 
you'd use millions of frames 
of animations, sound 
effects, tiles, textures, and 
the like, but often they just 
won't all fit in memory at 
the same time. 

One solution is object caching. 
bject caching lets you have as much data 
as you need. If extra memory is available, 
object caching lets you take advantage of 
it. I f extra memory is not available, howev- 
er, it will still run (with lower perfor- 
mance). This is ideal in the PC world, 
where the amount of available memory 
available varies wildly from system to sys- 
tem. A cacheable object is defined as a "set 
of data" that can be recreated entirely, 
either by loading it from the disk or by 
recomputing it. This usually applies to 
write-once, read-many data found on CD- 
ROM and ROM cartridges. 

The main component of a caching 
system is the cache manager, whose job is 
to provide virtualized accesses to objects, 
usually through an ID or handle. For 
example, to replace the conventional code: 

image *i[n=load_image("filename"); 
iin->put_iinage (screen, x,y); 

a cache system would use: 

cache.handle iin=cache_inanager. regis- 

ter_i[nage("filenatne") ; 
cache.manager.imageCim)- 

>put_image (screen, x,y); 

The function cache.manager. image 
does a quick check to see if the object is 



in memory and, if so, it returns a pointer 
to object data. If the object is not in 
memory, it reads it from the disk and 
returns a pointer to the newly loaded 
object. If there is not enough memory to 
load up the new object, the cache system 
scans all the cacheable objects and frees 
the oldest one. The cache manager keeps 
freeing the oldest cached object until 
memory can satisfy the allocation request. 
You can quickly access cache items using 
alookuptabletothelD. 

Dealing with Time Overflow 

Each time an object is accessed, the time 
marker is incremented and then stored in 
the last.accessed field of the cache item. If 
the last.accessed field is a short (2 bytes), 
you can only access something 65,536 
times before this overflows; but if it is a 4- 
bytelong, you can have 4 billion accesses. 
If an overflow occurs, the system will still 
work, but it will work poorly. Let's take a 
look at an overflow situation. First, there is 
an access of a large, infrequently used data 
item at time = 65,535. W e increment time 
and get an overflow, setting time back to 0. 
T hen we do two more accesses at time = o 
and time = 1. 

N ow let's say at time=l, there is not 
enough memory to load the object. The 
cache system goes to free the oldest object 
that appears to be the object from time=o, 
but is really the large object from 
time=65,535. The large object will never 
get freed! The disk will thrash, and the 
user will not think you are very cool. 

T here are two ways we can deal with 
this. First, you can check the time after 
each increment and see if it overflowed. 
This can be coded in assembly language as 
one instruction. If the time has over- 
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flowed, adjust all the cache object 
last.access times by dividing by some 
number (say the number 2). This will pre- 
serve the relative times for each object and 
give you more time values to work with. 

Or, you can check time periodically 
from within the game. W hen it goes 
above a threshold value, divide all the 
cached objects time value by 2. This solu- 
tion eliminates the need to compare each 
object access, and it is preferable for 
extreme speed- intensive needs, but it also 
creates the possibility that time will over- 
flow between checks. 

Memory Management 
and Fragmentation 

If you use a conventional memory man- 
ager you will have problems with memory 
constantly freeing and reallocation blocks 
of memory and thereby fragmenting. T he 
memory space becomes fragmented with 
little holes from cache objects that have 
been freed. If your memory is tight, you 
will get to a point where the holes are no 
longer big enough to satisfy a request. 

For example, suppose your memory 
layout looks like this: 

static object 
cached object 
static object 
cached object 
static object 

After freeing all the cached objects 
during a new allocation request, the lay- 
out looks like this: 

static object 
free 

static object 



free 

static object 

A Ithough the two frees put together 
might satisfy the request, you cannot span 
your object across the static object in the 
middle (that is, at least not unless you 
depend on hardware paging). 

The solution is easy. Keep two 
heaps. One heap is used to satisfy static 
allocation requests, and one for cached 
requests. You can simulate this with one 
heap by allocating the static requests at 
the bottom of the heap (growing up) and 
the cached requests at the top of the heap 
(growing down). 

As the static grows upward and 
needs more space, the objects in the 
cached space can be freed without any 
problem. 

Precache Modeling 

W hen a game starts, how do you know 
which objects to precache (or load into the 
cache)? You can leave the cache empty, 
but the disk will be hit every time some- 
thing new is accessed, which can be 
annoying to the user. Sometimes this is 
not noticeable. For example, Doom's pro- 
grammers did not precache the sound 
effects, and it didn't negatively effect the 
game play. 

If the game is simple enough, you 
can scan all the objects in a level and load 
up all the associated art and sound effects 
until it runs out of memory. This is fine in 
some games, but a more flexible game 
cannot predict at the start which objects 
will appear in certain levels. 

A much better solution is to use play 
statistics. H ave a level designer play a 
level several times through, and, as each 



J ona'than Clark 
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ctiing-ctiing" sound 
ttiot means you ore 
tlirostiing ijour tiord 

drives? Vour users 
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cache item is accessed, increment its 
counter. At the end of the level, save all 
the cache IDs and their access counts. 
Now, the next time the level is played, 
you'll know which IDs to use. Sort the 
IDs in descending order and load the 
most frequently accessed IDs first. Keep 
loading until you're out of memory or 
until they're all loaded. 

Cacheable Objects 

It doesn't make sense to cache an object 
whose size is smaller than a cache entry. 

A cache entry might look something 
like this: 

struct cache.item 
{ 

void *data; 

// NULL if object not loaded 

long last.access; 

// time stamp of last access 

unsigned char type; 

short file.number; 

// index into filename list 

long offset; 

// offset into file to find this object 
} ; 

The size of this data structure is 
4+4+1+2+4=15 + figure in 4 to 12 byte 
overhead for the memory manager node 
information, so anything less than or 
equal to 27 bytes should not be cached. 

W hen I was writing A buse (a game 
produced by Crack dot. Com and the 
first affiliated game to be distributed by 
rigin), I used caching as much as possi- 
ble. WhileAbuse was written primarily in 
C ++, 8% of the code was written in L I SP 
and interpreted during the game. A demo 
is available at http://crack.com or at 
ftp://ftp.odrom.com/pub/abuse (the 
demo includes a built-in level editor and 
LISP source code). Following is a list of 
cached objects I created while writing 
A buse: 

• Frames of animation 

• Tiles and textures 
■ Images 

• Particle animation data 

• Sound effects 

• Compiled LISP functions. 

A buse has a L I SP interpreter, which 
compiles the program at run time into a 



tokenized form and writes this out to a 
cache file. nee this has been done, LISP 
functions can then be accessed just like 
regular cache objects. 
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You can also use caching for com- 
putable operations to speed up your 
game. For example, say slamming an 
image right to left is faster than slamming 
it left to right, but you still need to draw 
the image both ways. W hen you cache in 
the frame, duplicate it and make one of 
the frames reversed. 

Caching is also well applied to 
memory compression. In a system that 
can only access data through a CD- 
ROM , a disk hit can be very irritating to 
a user. H ow should you deal with this? 
You can store all your data in memory 
compressed and decompress it into 
cacheable objects as memory becomes 



available. Decompressing data is almost 
always faster than aCD-ROM hit, and if 
your data compresses well, this solution 
will work well for you. 

Optimization 

W hen dealing with inner loop material, 
you should save a pointer to a cache item 
instead of asking the cache manager to 
look it up everytime. For example, use: 

image *img=get_img(tetxture); 
for (int i=0;i<1000;i++) 
img->put_image(screen , x , y ) ; 

instead of: 

for (int i=0;i<1000;i++) 

get_img(texture)->put_image 
(screen, x,y); 

Because you are not making any 
other cache request inside the loop, you 
can assume the object is still in memory. 
1 1 is usually safe to assume the last several 
cache accesses will be in memory, but you 
can run into problems with sound or 
multithreaded programs. If you start 
playing a large sound in the background, 
and the cache manager frees and reallo- 
cates it before it is done playing, you will 
hear static. Either play small short sound 
effects or use a cache-locking system with 
sound callback. 

The cache- locking system sets a bit 
in the cache item that says, "Don't free 
me." The sound system unsets this bit 
when the sound has finished playing. A 
lock and free system can be used to solve 
multithreading problems as well. Locks 
should not be obtained for long periods 
of time, though, because defragmantation 
cannot occur if an object is plugging a 
hole. Instead, use static allocation when 
you need "untouchable" objects for long 
periods of time. 

You can also run into trouble if you 
work with large data objects. For example, 
suppose you want to blend two 640- by- 
480-by-256 images together and display it 
on the screen. The most efficient way 
would be: 

char *scan_linel=get_img(imagel) 
->scan_line(0), 
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*scan_line2 = get_i[ng(image2) 
->scan_line(0), 

*screen_scan_line=screen 
->scan.line(0); 
for (int count=u*h;count;count~, 
scan_linel++, 

scan_line2++ , screen_scan_line++) 
*screen=tiiix (*scan_linel , *scan_line2) ; 

But if imagel and image2 don't fit into 
memory, you're in trouble You will either 
have to break the images into smaller parts 
or write two mixing routines— an efficient 
one and another that runs in a low- memo- 
ry environment by asl<ing for the cache 
item on each iteration. 

Finally, here are a few good tips I 've 
picked up when writing cache systems 
and memory managers. 

Optimize for small memory alloca- 
tions. C -H- programs tend to allocate and 
free small blocks of memory. I keep a list 
of stacks of pages for block sizes less than 
128 bytes. Then, if an allocation is less 



than 128 bytes, the allocation time is usu- 
ally a fast constant time. M emory profile 
your game and see what kind of alloca- 
tions are going on and how often, then 
optimize for your needs. 

Don't use virtual memory. Virtual 
memory involves writing pages to disk 
and reading them back. A cache system 
only needs to read, so it is much faster. 

I t's a good idea to word align all allo- 
cations to 4-byte boundaries. Though the 
x86 supports nonword aligned memory 
accesses, it does so only by reading twice 
T his can also make a significant difference 
if the stack is kept word- aligned. 

A helpful debug tool is to zero out 
all freed memory. Then, whenever a ref- 
erence to memory that is supposed to be 
free is used, a crash is likely to result and 
you can track it down easily. 

Another useful debugging tool is to 
pass a string with each allocation which 
can be used to quickly point out the source 
of memory leaks or hogs. The LINE and 



FILE macros can even be used if you get 
lazy. These strings can be eliminated from 
thefinal executable by a define: 

Sdefine MY_inalloc(size, string) my_mal- 
loc(size) 

The two conditions above, bad refer- 
ences and memory leaks, are a big cause of 
bugs in games and are often hard to track 
down. T hese two methods can save you a 
lot of sanity and keep your game stable 

Don't forget today's freaks could be 
tomorrow's reality. 64-bit pointers seem 
overkill right now, but a breakthrough in 
memory production cost is all that is need- 
ed to move them from high-end systems 
to personal PCs. Think of the games you 
could write with over 4G B of memory. ■ 

Jonathan Clark isa partner of Crad< dot 
Com and the author of Abuse. Contad: him 
via e-mail at jc@aad<.com or through Game 
Developer magazine 
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Be the hero of ijour 
clan or jusf hove fun 
hloining fhings up. 
Smorf developers 
should lohe note of 
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Hello and welcome! This is my 
first time wielding the cleaver 
on the Chopping Block, so I 
thought I'd introduce myself. 
M y name is M il<e M ichaels, 
and I 'm a software engineer in 
Southern California. Part II of 
my series on PC input man- 
agement appears in this issue on p. 40. 

N ow they've asked me to pen the 
C hopping Block. This was a difficult 
decision for me to make. n the one 
hand, writing a game review column has a 
certain attraction. On the other, I really 
wasn't interested in doing the column in 
the format that it had been rendered in 
previous issues. That is to say, I am not 
interested in hacking into a game's save 
file to figure out where and how every- 
thing is stored. If I 'm struggling to finish 
my own games, why would I spend time 
hacking into other people's creations? 

After a week of e-mail with the edi- 
tor of this column, we agreed that a 



change in format might be appropriate. 
I 'm going to try to structure these reviews 
at a higher level, while still maintaining a 
technical perspective. 

Lef s Get on with It! 

T his month we're going to take a look at 
M echwarrior 2, a combat simulation 
game based on FASA's BattleTech Uni- 
verse. I n the game, you assume the per- 
sona of a M echW arrior, one of your 
clan's elite, who achieves honor, rank, and 
prestige by piloting the enormous Battle- 
M echs (M echs) into combat against the 
rival clan. If this is all Greek to you, don't 
worry It reallyjust gives you an excuse for 
running about in a mobile tin can and 
blasting everything in sight. 

T he game allows two modes of play. 
For the goal- oriented, there is a career 
path option that lets you undertake and 
complete missions that garner you pres- 
tige, honor, and rank amongst your peers. 
T he ultimate reward for your selfless ser- 




In Activision's game, you assume the persona a MechWarrior. 
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vice is to battle for and become the leader 
of your clan. If you couldn't care less about 
becoming a clan leader but you still want 
to blow away a few M echs, the game pro- 
vides an unrecorded combat mode where 
you lead up to two other M echs into com- 
bat against a series of enemy M echs 

The cut-scenes must be seen to be 
believed. Rendered in high resolution, 
they look lil<e something you might see in 
a quality science-fiction movie. The only 
thing about them I didn't like was that I 
grew jealous of the freedom of movement 
that the choreographed M echs had that I 
didn't— but I 'm getting ahead of myself. 

The actual simulation takes place in 
a real-time, three-dimensional, polygon 
rendered environment. Everything 
appears flat shaded, the lack of texture 
mapping probably accounting for the 
excellent frame rates— even at the highest 
resolution. Speaking of which, the game 
may be played in standard VGA (320 by 
200) or either of two VESA high resolu- 
tion modes (640 by 480 or 1024 by 768). I 
found the middle resolution to be the best 
visually: standard VGA resolution is just 
too chunky, while the highest resolution 
made the enemy M echs look too small. 

The engine is also capable of a few 
special effects. I noticed some light source 
shading as well as a fog-and-dust-type 
effect on some of the levels. Transitions 
from day to night seemed to be accom- 
plished using progressive palette updates. 
There might be more effects in later lev- 
els, but my dexterity isn't such that I was 
able to find out. 

There are a few anomalies with the 
rendering engine. In certain situations, it 
looked like enemy M echs were walking on 
air. This usually occurred on a sloped sur- 
face and was probably a result of the lack 
of surface texture. Perhaps the most 
annoying artifact is the unrealistic per- 
spective of objects at a distance. Rather 
than appearing gradually on the horizon, 
objects such as mountains, buildings, and 
enemy M echs suddenly pop into existence 
as you near them. It'sa little disconcerting 
to know you are being fired upon, but you 
can't see the enemy M ech at all until 
you've taken that last step. 

You control your M ech using any 
number of standard input devices (and 



MECHWARRI0R2 



Suggested Retail Price: $59.95 
System Requirements: 486DX2/66, 
8MB RAM, 45MB free hard-drive space, 
VGA or SVGA graphics, Soundblaster- 
compatible soundcard, joystick, double- 
speed CD-ROM. 

some nonstandard ones as well). You need 
the keyboard regardless of which optional 
input devices you choose. There are so 
many commands, they couldn't all be 
mapped to joystick or mouse buttons. T he 
game supports input from a number of 
specialized joystick systems, including the 
Phoenix System, M icrosoft Sidewinder 
3D Pro, rudder pedals, and throttle con- 
trol. In addition. Virtual l/O's i-glasses 
head- mounted display are supported. 

The only real problem I had was the 
sensitivity of the controls. A fractional 
change in joystick position seemed to 
cause a disproportionate change in M ech 
position. I couldn't line up on an enemy 
M ech (even a stationary one) and hit it 
with a series of shots; I was never able to 
keep the target sighted in the reticle. 

T his problem was only aggravated by 
the higher- resolution modes. Couple the 
ultra- sensitivity of the controls with the 
longer lag times between handling user 
input (because it's taking longer to paint 
the screen), and you get a game 
unplayable in most people's resolution of 
choice. I would have appreciated some 
means of controlling joystick sensitivity. 

If you know anything about the Bat- 
tleM ech universe, you're going to appreci- 
ate the effort designers went through to 
make each mission coherent and logical in 
the general framework. Those unfamiliar 
with the universe will be grateful the game 
was designed so you don't have to read the 
extremely long and sometimes cryptic 
details of what is going on in the clan war. 
In addition to detailed mission briefings, 
there is extensive background information 
to let you figure out where you and your 
clan fit in the grand scheme of things 

The game's designers have also 
done an excellent job capturing the 
physics behind M ech movement and 
combat. The cockpit bobs as your M ech 
walks or runs (a la Doom's floating gun 



Activision Los Angeles 

10601 Wilshire Blvd. Ste. 1,000 

Los Angeles, Calif. 90025 

Tel: (310) 473-9200 

Fax: (310) 479-4005 

Web: http://www.activision.ccm/ 

affect). W hen you're running at full 
speed, it's much harder to make a sharp 
turn than when you're going half speed. 
W hen an enemy M ech fires and hits you, 
your cockpit rocks violently with the 
shock of the blast. Firing some of your 
weapons too often can cause your M ech 
to overheat and shut itself down— which 
can be fairly annoying if you have two or 
three enemy M echs using you for target 
practice at the time. 

Wrapping Up 

M echwarrior 2 is an enjoyable and (prob- 
ably for some) addicting game. If you get 
past the sensitive controls, it's fun blowing 
other M echs all over the landscape. The 
sound, cut- scenes, and transition scene 
graphics are excellent. W hile the polygon 
rendering engine is by no means a techno- 
logical breakthrough, it's smooth, fast, and 
sufficient to let you immerse yourself in 
theBattleTech universe. 

That's about it. Let me know what 
you think about the new direction this 
column is taking. Is it good, bad, would 
you rather we got rid of the it in favor of 
longer articles on perspective- correct tex- 
ture mapping? There's been discussion of 
diversifying the column to include book 
reviews as well as reviews of game devel- 
opment tools and environments. I'd like 
to make this column as useful and enter- 
taining as possible, so let me know what 
you would I ike to see. ■ 

M IkeM idiaels works for a small cnm- 
piler company in Irvine, Calif. Though 
offered numerousjobsin themmputer gaming 
industry, he has been unwilling or unable to 
takethepay out involved in such a transition. 
H e resides on the fringes of game develop- 
ment, living the life vicariously through 
friends on "the inside" Contact him via e- 
mail at mike@irvineoDm or through Game 
Developer magazine 
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Someone, I wish I could 
remember who, once said that 
music lives in between all the 
notes T he comment has since, 
quite appropriately, been 
applied to the art of animation, 
as in "A nimation lives in 
between all the frames." 
Beyond the Zen loopiness of the state- 
ment is an unavoidable kernel of truth; 
unavoidable, that is, for anyone who has 
attempted character animation. Although 
software tools can make it almost embar- 
rassingly easy to, say, move a starship 
across the screen, depicting a character 
with convincing mass, momentum, and 
personality still calls for skills and tech- 
niques that animators have been refining 
throughout this century— since long 
before the advent of the computer. 

1 1 seems that many novice animators 
or nonartists involved in game production 



assume that technology has somehow 
removed all or most of the hurdles 
between them and snazzy animated rou- 
tines. The truth is that it has made a lot of 
things easier, and one of those things is 
bad animation. Thanks to the computer, 
it's never been easier to create stiff, lifeless, 
uninspired animation; all too often, due to 
time constraints and laziness, that's what 
people are creating. 

D oug A berle, M aster A nimator at 
Will Vinton Studios— and perhaps best 
known to SI G GRAPH attendees as cre- 
ator of the animated short Fluffy— 
observes that "the computer should be a 
tool, not a style. The basics of Squash 
and Stretch remain the same." Com- 
putoons president Bob Terrell (another 
Vinton alum) goes a step farther: 'There 
should be a sticker on the software box 
that says Talent Not Included." If you're 
not already familiar with the principles of 




"Martin [Hash] kids me tliat I used liis spline- based modeling tool to create a polygonal cliar- 
acter," Doug Aberle says of Fluffy, liit of tlie SIGGRAPH95 Electronic Tlieatre. 
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Squash and Stretch, or if you've been 
thinking the right software pacl<age 
would mal<e your first animation project a 
snap, I hope you'll keep reading. I think 
I 've got just about enough space here to 
impart a healthy respect for the work 
involved in character animation and to 
give beginners some idea of how to go 
about it. 

Les Pardew, president of game pro- 
duction house Sapphire Inc. (where 
artists outnumber programmers nearly 
four to one), makes it quite clear why you 
should care: "Production values have gone 
up tremendously. To compete in this 
industry you've got to have really superior 
graphics or people just don't accept it as a 
game anymore." W e've all seen too many 
games fat with fancy graphics but starving 
for gameplay, but we've also seen the 
extent to which high quality graphics can 
enhance the overall experience. All other 
things being equal, the better- looking 
game captures the player's attention and 
imagination, and solid character anima- 
tion can make or break that overall look. 

Know Your Roots 

The key to good animation is in the very 
definition of the word. Though many 
would assume that "animate" means "to 
make move," its Latin root really means 
"to bring to life" The computer is good 
at making things move on the screen but 
making them seem alive is up to you. 
This can only come from an in-depth 
understanding of both traditional anima- 
tion techniques and real- life movement. 



As almost any animator will tell you, 
one good starting point is The Illusion of 
L ife (H yperion, 1981) by Frank Thomas 
and lliejohnston. Recently reissued, this 
massive tome contains the combined wis- 
dom of these two renowned animators, 
who worked at Disney Studios from the 
mid 1930s until 1978, during which time 
they helped raise animation from a crude 
novelty to an art form. You may not be 
going after a Disney look, but this book 
covers all the basics every character anima- 
tor should employ. 

A nother way to start gaining an 
appreciation for character animation is to 
really watdi some of the classics: Disney 
films, of course, and the old Looney 
Toons and Tex Avery collections are all 
worth a close look, though you can skip 
the H anna Barbera stuff. C lassie live 
action films can help too: Aberle draws 
inspiration from the films of Laurel and 
H ardy, other animators often cite Buster 
Keaton and C harlie C haplin, but what 
you choose to pay particular attention to 
really depends on what you plan to ani- 
mate I find Douglas Fairbanks and E rrol 
Flynn great to watch for action. In gener- 
al, older films tend to have longer takes, 
which let you watch the movement 
through its course, while modern films are 
composed of quicker cuts. Use a slow- 
framing feature or the frame advance on 
your VCR or laserdisk to observe every 
stage of the action, and try to isolate the 
extremes of motion. These correspond to 
the key poses from which an animator 
builds a routine. 



Casting Call 

Of course, character animation must start 
with a character, and that character starts 
with a design. The animator who has the 
luxury of designing his or her own charac- 
ters deserves the envy of every H ollywood 
casting director, for therein lies the oppor- 
tunity to literally create the perfect "actor" 
for the role Less enviable is the animator 
who must bring to life a character 
designed by a nonartist. The difficulty in 
this not uncommon situation comes in 
matching the demands of the concept with 
the demands of the medium. 

The first consideration in character 
design should be the game style and target 
audience. As Terrell points out, 'Terms 
like 'cute' or 'scary' can mean vastly differ- 
ent things to different audiences." A more 
adult audience may be scandalized by the 
violent death scenes in a fighting game 
kids think is cool. W hat's deliciously 
creepy to a mature game player might 
cause nightmares in young children, while 
what kids find enjoyably spooky might 
seem simply corny to an older sibling. 
Keep in mind that much of the game's 
personality will reside in the depiction of 
its characters. 

T he player's view of the scene and of 
the characters in it is another important 
design consideration. H ow much of the 
character is seen— and from what angles- 
can help the animator determine what 
level of detail needs to go into various 
aspects of the design. A s I 'II discuss later, a 
character designed for side- scrolling game- 
play can have very different needs than one 
featured in a highly detailed cinematic 
sequence T he key point is that the charac- 
ter must work from every anglethat will be 
seen. Conversely, the animator can save 
precious time by not putting design effort 
into angles that won't be seen. 

Before even turning to their sketch- 
book though, many animators will first 
sketch out ideas for the character's person- 
al history. T his isn't strictly the artist's job 
and may be unnecessary if a complete 
script has already taken care of these 
details or if the character is a straightfor- 
ward monster or a hero who'll never be 
seen out of battle armor. Then again, such 
insight into the character can be helpful 
even in the latter cases: think of how much 
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more interesting Toll<ein's G ollum was 
because of his history. 

Creating animation for the Cyclone 
Studios/3DO title Captain Quazar, Ter- 
rell found himself stopping production to 
flesh out the musclebound hero's back- 
ground. "W e did a full history for Q uazar, 
including a lot of stuff that doesn't even 
really enter into the game It was unortho- 
dox to stop in the middle of the project to 
do it, and it did take up valuable time, but 
we felt it was necessary to get a good feel- 
ing for the character we were animating." 

N ext stop on the road to a good char- 
acter design is the model sheet. By this 
time, the animator should have a very clear 
idea of the character's personality and of 
what sort of action will be called for. It's 
time to determine what the character looks 
like in detail. ne common misstep is 
drawing the character standing rigidly at 
attention from square front and side 
views— unless that's appropriate behavior 
for the character. Rather, the model sheet 
should depict the range of attitudes, 
expressions, and general positions that will 
be called for in the animation. 

M oving on from the model sheet is 
what is known as inspirational reference or 
atmosphere sketches. T hese are more fully 
realized drawings, paintings, renderings, or 
even sculptures depicting the character, 
often in a setting. Terrell, whose back- 
ground is in claymation (at W ill Vinton 
Studios he worked on the California 
Raisins and the Domino Pizza N old), now 
does all his animation on the computer, 
but he still creates characters in clay for 
inspirational reference. "It helps for the 
artist to be surrounded with actual, physi- 
cal things relating to the character," he 
notes. And though artists working for 
Animation M agic also do their animation 
on the computer, traditional hand-painted 
animation eels of the same characters hang 
on the officewalls as inspiration. 

Plan to be Spontaneous 

Does it seem likel'm taking a long time to 
get around to talking about the act of ani- 
mating? I n a recent 3dSite I RC panel dis- 
cussion on New Directions in Character 
Animation, Tim Johnson, Animation 
Director for Pacific Data Images, said, "I 
believe passionately that diving in leads to 



crummy animation. W e all like to imagine 
ourselves as the great jazz improvisors of 
animation. Not true. If you don't act it 
out, draw it, think it through, your move- 
ment will probably suffer." The medium 
presents a paradox for an animator to 
overcome A n animated scene or routine is 
usually short and the action quick and full 
of life But the process of making an ani- 
mation is drawn-out and painstaking. Per- 
haps the greatest challenge is not to be 
defeated by that process, to resist being 
bogged down by preparations that can sap 
enthusiasm, and to reject the impulse to 
simply skip all the careful preparation and 
rush into animating the scene 

T hough it is much more practical to 
revise a computer animation than is the 
case with either eel animation or clayma- 
tion, it's still important to approach the 
scene with a well-thought-out plan in 
mind. W hile spontaneous creative flour- 
ishes will, hopefully, quite often enliven 
the actual animation process, the principle 
place and time for improvisation is in the 
mind of the animator and in the sketch- 
book, before ever bringing the project to 
the computer. 

To hear Thomas and Johnston tell it, 
the halls and offices of Disney Studios 
were filled with animators acting out rou- 
tines for their characters to get a feel for 
the movement, a tradition started there by 
W alt D isney himself. A berle slyly refers to 
a reference tape of himself acting out the 
part of F luffy (no, he won't show it to 
you). Even when the character is nonhu- 
manoid it can help greatly for the animator 
to mimic the movement— as closely as 
possible, anyway— to get a better sense of 
the interplay of muscles and the shifting of 
balance. Throughout, special attention 
should be paid to anticipation and follow- 
through— the movements that lead up to 
and follow major actions. These are the 
small touches that make a movement more 
convincing and actually help to focus the 
audience's attention on the major action. 

nee the movement is mapped out 
in the animator's mind, it's time to begin 
working out the key poses in a series of 
small, rough "thumbnail" sketches. W hen 
making such sketches, the artist should not 
start with the character's head, a common 
practice Almost all movement originates 



in the pelvis or shoulders, and a sketch 
meant to convey motion should follow the 
focus of that action. At this stage, the 
drawing should depict mass and momen- 
tum more than surface detail. Disney 
encouraged animators to work in a quick, 
rough style, knowing the image retained 
more vitality this way. (M ost of the "clean- 
up" was done later by junior animators.) 
Though a computer animator's sketches 
might contribute less directly to the final 
rendered product, capturing that energy 
beforehand is still a critical step. 

nee the animator has expanded on 
the thumbnails to refine the key poses, the 
next step is to create a storyboard; a sort of 
visual map for the routine, progressing 
from pose to pose and taking framing into 
account. An important principleto keep in 
mind at this stage is silhouetting. That is, 
staging the action in such a way that it can 
be clearly seen by the audience, being care- 
ful not to allow important details or ges- 
tures to be muddied or hidden. 

Squash and Stretch is one of the 
most basic principles of animation yet is 
unfortunately neglected by some computer 
animators. The idea is that living organ- 
isms—a group that includes most of our 
characters— are not as rigid in their move- 
ments as is a folding chair or a slide rule or 
any other inanimate articulated object. In 
the course of a movement muscles flex and 
extend, flesh sags or tightens, and these 
effects impart realism to an animation and 
can be exaggerated by the animator to 
enhance movement. H owever, it's relative- 
ly easy to model a character on the com- 
puter with limbs of the right proportions 
and joints in the right places, to move it 
around like a marionette and then wonder 
why the action looks stiff and unconvinc- 
ing. If an artist has managed to capture the 
vitality and weight of a movement in the 
sketchbook phase, it would be a shame to 
abandon it at this stage. Squash and 
Stretch has its place even in three-dimen- 
sional modeling. 

nee the animator has brought all 
this preparation to the computer, there's at 
least one more impulse to resist— the very 
natural wish to finally see everything ren- 
dered in sparkling three-dimensional 
detail. It's usually more economical to first 
render a rough pose test to check move- 
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Computoons designed and animated Captain Quazar and otiiers for tlie 3D0 titie produced by 
Cycione Studios. Animation inciuded a 90-second rap video. Image courtesy of Tlie 3D0 Co. 



ment and timing: forget about texture 
mapping and dramatic lighting, don't use 
antialiasing, don't even thinl< about ray- 
tracing. A quicl< render will show how well 
the action plays and point out areas where 
the timing is off or the movement doesn't 
quite read. ne of the things to really lool< 
for at this stage is a sense of solidity and 
weight to the character. T his is one of the 
most difficult things to simulate well and 
will I ikelytal<e careful tweal<ing. 

The Play's the Thing 

This all may sound overly ambitious for 
what is, after all, a game. Yet even if you 
eschew (gesundheit) fancy splash 
sequences, you should be wary of underes- 
timating the importance of good character 
animation for gameplay routines. Game- 
play is after all where the player will be 
spending the most time; if the character 
movement is out of character, it's just not 
as captivating. 

To remain visually interesting, char- 
acters—especially the main character- 
should have a variety of movement rou- 
tines: wall<ing, jumping, tripping, and so 
on. ne shortcut to tal<e advantage of is 
the character's symmetry; the routines can 
often be mirrored, so that when flipped a 
left turn routine, for example, can also 
serve for a right turn. Though this may 
mean that your hero's blaster suddenly 
shifts from his right hand to his left, Ter- 
rell cautions the animator not to obsess. 
"As an animator, the lack of continuity 
was difficult to accept, but the game for- 
mat allows you to hide a multitude of 



sins; sprites are only an inch or so on the 
screen and fewer frames are rendered. 
T he game designers said not to worry, no 
one would notice, and you don't, really." 
W hich is not to say that the C omputoons 
artists let Captain Quazar get sloppy. 
W ith the lower frame count in gameplay 
routines, they took advantage of the 
opportunity to retouch images frame by 
frame. 

Actually, two distinct three-dimen- 
sional models were created of Q uazar: one 
for the cinematic sequences and another 
for gameplay with exaggerated features so 
that details would read in the smaller 
scale The trick was to create models that 
were different yet still read easily as the 
same character, and the key to that was 
having intentionally designed a character 
that was appealing and still simple enough 
to be flexible. 

How Much is 
the Free Lunch? 

Inverse Kinematics is one of the buzz- 
words that struggling novice animators 
cling to faithfully, sure that it promises a 
future of hassle- free character animation. 
While Inverse Kinematics certainly has 
its uses and its devotees, it should be 
understood that it comes with its own 
challenges and frustrations, too. What 
Inverse Kinematics does is allow the ani- 
mator to establish hierarchical chains; the 
shin bone's connected to the knee bone, 
knee bone's connected to the thigh bone, 
and so on, and establish movement para- 
meters for those chains. Then by "tug- 



ging" on the foot, for example, you can 
watch the leg extend, pivoting at the hip 
and bending at the knee in a natural 
manner. 

Natural, that is, if you've made all 
the right connections and set appropriate 
parameters. Inverse Kinematics is gener- 
ally a scripted process, and getting every- 
thing connected just right can be an elab- 
orate and time-consuming endeavor. 
W hile it's possible to get the same move- 
ment in an animation without using 
Inverse Kinematics, kinematics can defi- 
nitely save time further down the road 
once an animator has established a library 
of parameters for different routines. 

T hough it's still a more or less high- 
er-end fantasy, the mention of motion 
capture can also tend to invoke visions of 
flawlessly realistic character movement 
without all the work. Yet while many 
accomplished animators are intrigued by 
the possiblities, others suggest that at this 
stage in the technology it may take more 
effort to fix the captured data than to ani- 
mate a scene from scratch. "M otion cap- 
ture gets you about 60% of the move- 
ment," Sapphire's Pardew estimates, 
while the rest needs to be tweaked or 
completely redone by a skilled animator 
to look right. M otion capture is probably 
most useful for sports games calling for 
realistic movement. But for many games, 
realistic movement actually falls short of 
the mark. 'T hat's not the point of anima- 
tion," Tim Johnson states. "G reat anima- 
tion caricatures reality and makes it art- 
ful. It caricatures motion to make a dra- 
matic or narrative point." H eroic, exag- 
gerated movement is more the stuff of 
video games. 

Ken Cope, Senior A rtist at Acclaim 
Coin-Operated Entertainment puts forth 
his aphorism #3C: "The closer reality is 
approximated, the more glaring any dis- 
crepancy becomes." M aybe the real art of 
animation is to be convincing without 
being too realistic. After all, if reality 
were all that, who'd bother playing our 
games? ■ 

David Sieks is a CDntributing editor to 
Game Developer. You can oantact him via 
email at 103302.301@compuserve.com or 
through G ame D eveloper magazine 
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